Image forming apparatus, control method of image forming apparatus, server apparatus, control method of server apparatus, computer program product, and storage medium

Abstract

An image forming apparatus, a control method of an image forming apparatus, a server apparatus, a control method of a server apparatus, a computer program product, and a storage medium are provided. An image forming apparatus is provided. The image forming apparatus stores a public key and a user profile of a user in association with each other in a storage, the public key being obtained from a terminal of the user and forming a pair with a private key held in the terminal, performs a first authentication for authenticating the user by verifying a digital signature received from the terminal using the public key, and in a case where authentication of the user via the first authentication is successful, allows the user to log in to the image forming apparatus using the user profile stored in association with the public key.

Description

Technical Field

[0001] The technology disclosed herein relates to techniques for authenticating users of a device, and particularly to image forming apparatus, control methods for image forming apparatus, server equipment, control methods for server equipment, computer program products, and storage media. Background Technology

[0002] In recent years, some companies have used Active Directory (registered trademark) or LDAP servers from Microsoft to centrally manage employee accounts. Image forming equipment placed in the offices of such companies can be logged into using usernames and passwords managed through the server.

[0003] Furthermore, there is a growing number of companies using cloud servers known as Identity Providers (IdPs), such as Microsoft Entra ID (formerly known as Azure Active Directory) from Microsoft and Google Workspace from Google, to centrally manage employee accounts. For example, the image forming equipment described in Japanese Patent Application Laid-Open No. 2024-7209 collaborates with an IdP and uses usernames, passwords, and one-time passwords for multi-factor authentication to authenticate users intending to use the image forming equipment.

[0004] Recent known technologies for authenticating users include FIDO 2.0, specified by the Fast Identity Online (FIDO) Alliance. This technology uses biometric authentication on the user's device and verifies data signed with a private key via the device on the authentication server side.

[0005] In the case of an image forming apparatus as proposed in Japanese Patent Application Publication No. 2023-37169, FIDO authentication technology can be used to enable the use of external services from the image forming apparatus.

[0006] However, logging into the image forming equipment using an account managed on the server requires considerable effort in entering a username and password, making it unuser-friendly. In recent years, the addition of one-time passwords for multi-factor authentication has further reduced this user-friendliness.

[0007] In user-friendly image forming equipment login methods, the equipment provides authentication via IC cards or similar employee ID cards. However, there is a risk of IC card forgery, and therefore this method cannot be considered sufficiently secure. Summary of the Invention

[0008] The technology disclosed herein provides a method for logging into an image forming device that is both user-friendly and secure.

[0009] One aspect of this disclosure provides an image forming apparatus, comprising: a storage component for storing a public key and a user profile associated with each other in a memory, the public key being obtained from the user's terminal and paired with a private key held in the terminal; a first authentication component for performing a first authentication for authenticating the user by verifying a digital signature received from the terminal using the public key; and a login component for allowing the user to log in to the image forming apparatus using the user profile stored in association with the public key if the user is successfully authenticated via the first authentication.

[0010] Another aspect of this disclosure provides a server device connected via a network to an image forming apparatus, the server device comprising: a fourth authentication component for performing a fourth authentication for authenticating a user using an authentication server; an acquisition component for obtaining from the authentication server a user profile of the user authenticated by the fourth authentication; a registration component for storing a public key and the user profile of the user in association in a storage component, the public key being obtained from the user's terminal and paired with a private key held in the terminal; a fifth authentication component for performing a fifth authentication for authenticating the user by verifying a digital signature received from the terminal using the public key; and a transmission component for transmitting the user profile stored in association with the public key to the image forming apparatus if the authentication in the fifth authentication is successful.

[0011] Another aspect of this disclosure provides a control method for an image forming apparatus, the image forming apparatus including a memory for storing a public key and a user profile associated with each other, the public key being obtained from the user's terminal and paired with a private key held in the terminal, the control method comprising: performing a first authentication, the first authentication being used to authenticate the user by verifying a digital signature received from the terminal using the public key; and, if the authentication of the user in the first authentication is successful, allowing the user to log in to the image forming apparatus using the user profile stored in association with the public key.

[0012] Another aspect of this disclosure provides a method for controlling a server device connected to an image forming apparatus via a network. The control method includes: performing a fourth authentication for authenticating a user using an authentication server; obtaining a user profile of the user authenticated by the fourth authentication from the authentication server; storing a public key and the user profile of the user in a memory in association with each other, the public key being obtained from the user's terminal and paired with a private key held in the terminal; performing a fifth authentication for authenticating the user by verifying a digital signature received from the terminal using the public key; and, if the authentication in the fifth authentication is successful, transmitting the user profile stored in association with the public key to the image forming apparatus.

[0013] Another aspect of this disclosure provides a computer program product comprising a program that, when executed by a computer, implements the steps of the method described above.

[0014] In another aspect, this disclosure provides a non-transitory computer-readable storage medium storing a program that, when executed by a computer, implements the steps of the method described above.

[0015] The above configuration can provide a method for logging into an image forming device that is both user-friendly and secure.

[0016] The features of this disclosure will become apparent from the following description of embodiments with reference to the accompanying drawings. The following description of the embodiments is given by way of example. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and, together with the specification, serve to explain the principles of the embodiments.

[0018] Figure 1 This is a diagram showing the system configuration.

[0019] Figure 2A This is a diagram showing the hardware configuration of the MFP.

[0020] Figure 2B This is a diagram showing the hardware configuration of a mobile terminal.

[0021] Figure 3 This is a diagram showing the software configuration.

[0022] Figure 4A This is a diagram showing an example of a user database used for local accounts.

[0023] Figure 4B This is a diagram showing an example of a character information table.

[0024] Figure 4C This is a diagram showing an example of a user profile table.

[0025] Figure 5 This is a diagram showing the user interface displayed on the MFP's operation panel.

[0026] Figure 6A This is a diagram showing the user interface used for login function settings.

[0027] Figure 6B This is a diagram showing the user interface used for local account management.

[0028] Figure 6C This is a diagram showing the user interface used for editing user accounts.

[0029] Figure 7A This is a diagram showing the user interface for authentication server settings related to server accounts.

[0030] Figure 7B This is a diagram showing the user interface for managing the passkey for server accounts.

[0031] Figure 8A This is a diagram showing the changes in the operation panel screen during password authentication.

[0032] Figure 8B This is a diagram showing the changes in the operation panel screen during key registration.

[0033] Figure 9 This is a diagram showing the key registration sequence.

[0034] Figure 10 This is a diagram illustrating the key authentication sequence.

[0035] Figure 11A This is a diagram showing the screen transition during key registration on a mobile terminal.

[0036] Figure 11B This is a diagram showing the screen transitions during key authentication on a mobile terminal.

[0037] Figure 12 This is a flowchart illustrating the key registration process.

[0038] Figure 13 This is a flowchart illustrating the key authentication process.

[0039] Figure 14 This is a flowchart illustrating the user profile synchronization process.

[0040] Figure 15 This is a diagram illustrating the system configuration according to the second embodiment.

[0041] Figure 16 This is a diagram showing the hardware configuration of the FIDO server.

[0042] Figure 17 This is a diagram illustrating the software configuration according to the second embodiment.

[0043] Figure 18 This is a diagram showing the screen transition of the operation panel according to the second embodiment.

[0044] Figure 19 This is a flowchart illustrating the key registration process according to the second embodiment.

[0045] Figure 20 This is a diagram illustrating the screen transition of a mobile terminal according to the second embodiment.

[0046] Figure 21 This is a flowchart illustrating the key authentication process according to the second embodiment. Detailed Implementation

[0047] In the following, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments are not intended to limit the scope of the claims. Several features are described in the embodiments, but not all of them are required, and several such features can be appropriately combined. Furthermore, in the drawings, the same reference numerals are given the same or similar configuration, and redundant descriptions are omitted.

[0048] First Embodiment

[0049] In this embodiment described below, as an example of an image forming apparatus according to this embodiment, a multi-function peripheral device (MFP) equipped with functions such as copying, printing, and scanning is used.

[0050] Note that in this embodiment, digital signature verification technology, such as Online Quick Authentication (FIDO), is used as the authentication mechanism for users to access functions or services provided by the image forming device. Specifically, the technology described in this embodiment relates to a mechanism for authenticating users by performing biometric authentication with the user on a mobile terminal (information processing device) and verifying the digital signature data output in response to successful authentication on the image forming device side. As described below, one advantage of this embodiment is that it incorporates digital functions corresponding to FIDO services using FIDO technology into the image forming device. Recently, FIDO authentication credential information has been referred to as a key. Key information consists of a credential ID, a public key, and a private key. The user's terminal possesses the credential ID, public key, and private key as key information. On the other hand, the FIDO-enabled server does not possess a private key but possesses the credential ID and public key as key information. FIDO is often referred to as a highly secure multi-factor authentication method resistant to phishing.

[0051] FIDO is given here as an example of such a mechanism, but it must be understood that the technology disclosed herein is not limited to the standards specified by the FIDO Alliance. Furthermore, authentication on mobile terminals is not limited to biometric authentication. For example, authentication via knowledge elements such as passcodes can be performed.

[0052] System Configuration

[0053] Now refer to Figure 1 The system configuration according to this embodiment is described. In this embodiment, the MFP is expected to be placed in a company office. The mobile terminal 102 is a mobile terminal such as a smartphone. The mobile terminal may be a terminal with iOS installed from Apple or a terminal with Android (registered trademark) installed from Google, etc. The mobile terminal 102 can communicate with the MFP 101 via access point 103 and LAN 104 of a wireless local area network (wireless LAN).

[0054] Furthermore, if the MFP 101 has a wireless LAN access point function, the mobile terminal 102 can be configured to connect to the wireless LAN access point function of the MFP 101 and communicate directly. Although not shown, multiple MFPs with the same configuration as the MFP 101 connected to the network can exist in an office.

[0055] Authentication server 105 is a server used to centrally manage employee accounts within the company. Authentication server 105 can be a virtual server established in a cloud connected via the Internet, or it can be a field server directly connected to LAN 104. As an authentication server 105 set up on the Internet, it can use Microsoft Entra ID from Microsoft, Google Workspace from Google, or similar identity providers (IdPs). Alternatively, as a field server directly connected to LAN 104, it can use Active Directory (registered trademark) from Microsoft or an open-source LDAP server, etc.

[0056] In the example described below, it is assumed that a Microsoft Entra ID from Microsoft is used.

[0057] Hardware configuration of MFP 101

[0058] Figure 2AThis is a simplified diagram showing the hardware configuration of the MFP 101. The CPU 201 is the central processing unit (processor) that controls all operations of the MFP 101. Random access memory (RAM) 203 is volatile memory and working area, and is used as a temporary storage area for loading various types of control programs stored in read-only memory (ROM) 202 and hard disk drive (HDD) 204.

[0059] ROM 202 is a non-volatile memory that stores the boot program of MFP 101. HDD 204 is a non-volatile hard disk or flash memory storage unit with a capacity greater than RAM 203. The program used to control MFP 101 is stored in HDD 204. In addition, the operating system (OS) and application programs are stored in HDD 204.

[0060] When MFP 101 is booted, CPU 201 executes the boot program stored in ROM 202. The boot program is configured to read the OS program stored in HDD 204 and load the program into RAM 203. While the boot program is executing, CPU 201 then executes the OS program loaded into RAM 203 and performs control of MFP 101. Furthermore, CPU 201 reads data used in the operation of the control program from RAM 203 and writes that data into RAM 203.

[0061] Note that in this embodiment, a single CPU 201 in the MFP 101 performs the processes indicated in the following sequence diagram. However, in other embodiments, the MFP 101 may have a different configuration. For example, multiple CPUs or microprocessors (MPUs) may be used in a configuration to perform the processes indicated in the following sequence diagram. Some of the processes described below may be performed using application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or similar hardware circuitry.

[0062] The operation panel 205 is a touch-operable display (touch panel). The printer 206 is a printer engine that prints print data received from an external device via the communication unit 208 and digital data obtained from the scanner 207. The scanner 207 is a scanner device that scans paper documents and converts them into digital data. The communication unit 208 is a network interface for connecting to the Internet or an office LAN, etc.

[0063] Hardware configuration of mobile terminal 102

[0064] Figure 2BThis is a simplified diagram showing the hardware configuration of the mobile terminal 102. The CPU 211 is the central processing unit (processor) that controls the overall operation of the mobile terminal 102. The RAM 213 is volatile memory and working area, and is used as a temporary storage area for loading various types of control programs stored in the ROM 212 and flash memory storage unit 214.

[0065] ROM 212 is a non-volatile memory that stores the boot program of the mobile terminal 102, etc. Flash memory 214 is a non-volatile memory storage unit with a capacity greater than that of RAM 213. The program used to control the mobile terminal is stored in flash memory 214. The OS and application programs are also stored in flash memory 214.

[0066] The operation panel 215 is a display (touch panel) that can be operated by touch.

[0067] Camera 216 is a camera module capable of capturing photos and videos, as well as QR codes (registered trademark). Front-facing camera 217 is a camera capable of capturing images of the mobile terminal user and performing facial authentication as a type of biometric authentication. Fingerprint sensor 218 is a sensor capable of fingerprint authentication as a type of biometric authentication. Communication unit 219 is a network interface for wireless communication.

[0068] Hardware configuration of authentication server 105

[0069] The authentication server 105 consists of a virtual server built in the cloud and a general-purpose computer such as a personal computer. The authentication server 105 includes a communication interface, a CPU, and memory. The CPU executes a program loaded into memory to receive authentication information, perform authentication processing, and respond with the authentication result. Details will not be described further.

[0070] Software Configuration

[0071] Figure 3This is a simplified diagram illustrating the software configuration of MFP 101 and mobile terminal 102. MFP 101 includes an operation unit login service 301 for authenticating users of MFP 101. The operation unit login service 301 includes a login processing unit 302, a server communication unit 303, and a FIDO service 304. The login processing unit 302 displays a login screen on the operation panel 205, authenticates the user based on authentication information entered via the operation panel, and logs the user onto the operation panel. The server communication unit 303 has the capability to communicate with servers such as authentication server 105. The FIDO service 304 includes web server functionality capable of communicating using the Hypertext Transfer Protocol (HTTP). It also includes authentication functions such as WebAuthn (Web Authentication) specified by the FIDO Alliance or the World Wide Web Consortium (W3C).

[0072] The MFP 101's operating unit UI service 305 provides a user interface for users logged into the operating panel to access functions. The user interface provided by the operating unit UI service 305 includes menus for users to select functions, applications, and a UI platform for controlling screen transitions. Specifically, it includes a "Copy" application for providing the copy function UI, a "Print" application for providing the printing function UI, and a "Scan and Transfer" application for providing the UI for transferring scanned documents externally.

[0073] Printer control unit 306 is a software module that controls printer 206, and scanner control unit 307 is a software module that controls scanner 207. Each software module provides an application programming interface (API) to applications used to operate printer 206 and scanner 207. Although not shown, the software configuration of MFP 101 may include driver software for controlling the operating system and various types of hardware.

[0074] Mobile terminal 102

[0075] The OS 311 of the mobile terminal 102 can be Apple's iOS, Google's Android (registered trademark), or a similar OS installed on the terminal. The authenticator 312 is software with FIDO authenticator functionality designated by the FIDO Alliance. The functionality of the authenticator 312 can be incorporated into the operating system (OS 311). The camera application 313 is an application used to control the camera 216 and the front-facing camera 217 to take photos and videos. It may also provide functionality for capturing and decoding QR codes. The web browser 314 is software that runs as a client function for HTTP communication. The web browser 314 can be Apple's Safari, Google's Chrome, or Microsoft's Edge, etc.

[0076] Authentication server 105

[0077] The authentication server 105 includes an authentication / authorization service 321, a REST API 322, a user management unit 323, and an application management unit 324. The authentication / authorization service 321 includes the following functions: transmitting an HTML authentication screen to clients accessing the authentication server 105, obtaining username, password, and one-time password input, and authenticating the user. The authentication / authorization service 321 also includes protocol functions for OAuth 2.0, OpenID Connect, WS-Federation, or SAML 2.0, and uses these protocols to authenticate clients and users attempting to access the server. The REST API 322 provides a Representational State Transfer (REST) ​​API. For example, Microsoft Entra ID from Microsoft provides a REST API called the Graph API, and information managed by the user management unit 323 can be accessed from the client using the REST API. The user management unit 323 manages information for multiple users, including usernames, passwords, email addresses, and user permissions. The application management unit 324 manages information including client IDs and client secrets used in OAuth 2.0 or similar protocols, as well as application permissions. Furthermore, the redirect URL, serving as the destination for the OAuth 2.0 access token, can be associated with and registered with the client ID. It is expected that the administrator of authentication server 105 will pre-register the client ID, client key, and redirect URL used to receive OAuth 2.0 authentication / authorization requests from MFP 101 or the FIDO server 106 of the second embodiment.

[0078] User Account

[0079] Figures 4A to 4CAn example of data stored in HDD 204 of MFP 101 is shown. Figure 4A User database 401 is a simplified diagram illustrating a user database used for local accounts. MFP 101 stores and manages user database 401, which includes user account information, in HDD 204. Note that databases from other nodes on the network can be used after encryption and anti-counterfeiting measures are implemented for communication paths and storage. User database 401 stores user IDs, passwords, key information used in FIDO authentication (credential ID and public key), roles, and email addresses, etc. Note that user database 401 includes items (user ID, display name, role, email address) corresponding to the user profiles included in user profile table 403 described below. Therefore, user database 401 can also be referred to as a database storing user profiles.

[0080] "User ID" is an identifier or identification information used to identify the user. "Password" is the password used for authentication. "Public Key" is a public key that pairs with the private key stored on the user's mobile device, etc. "Role" is information indicating the user's usage rights on the MFP 101. Examples of various roles and usage rights are provided in... Figure 4B The role information is indicated in Role Information Table 402. Roles and permissions are associated and registered in Role Information Table 402. In addition to the roles provided when the MFP 101 is shipped from the factory, users can also set detailed usage permissions and create new roles. "Email" is the user's email address.

[0081] As described below Figure 6B User account management screen 602 or Figure 6C The user account editing screen (UI 603) is used to register, edit, and delete user account information. Figure 4C User profile table 403 indicates a table that associates and stores key information, user profiles for server accounts, access tokens, and refresh tokens. Key information includes each user's credential ID and public key. User profiles include each user's user ID, display name, role, and email address. Data in user profile table 403 is stored in HDD 204 via the key registration process described below. Registration data can be processed via... Figure 7B Use the 702 UI to view or delete the key management interface for your server account.

[0082] The data is read / written from the login processing unit 302, server communication unit 303, and FIDO service 304 of the operation unit login service 301.

[0083] User authentication function

[0084] Next, we will refer to Figure 5 , Figures 6A to 6C and Figures 7A to 7B Describe the user authentication functionality provided in MFP 101. Note that in this embodiment, two types of user authentication will be described. The first is authentication using a password entered by the user on the operation panel. The second is authentication of the user's operation unit login service 301 using PKI technology specified by FIDO. In other words, for the latter, it uses the result of verifying the signature data obtained by encrypting the challenge with the private key using the public key to authenticate the user; this is referred to as user authentication. Note that in this embodiment, in addition to such user authentication, authentication is performed with the mobile terminal to authenticate the owner of the mobile terminal. In this way, multiple types of authentication exist in this embodiment.

[0085] Figure 5 This is a simplified diagram showing the login screen displayed on the operation panel 205 and the menu screen displayed after login. Figures 6A to 6C This is a schematic diagram showing the settings screen for setting up login methods and managing user accounts. Figures 7A to 7B This is a schematic diagram showing the setup screen related to the collaboration between MFP 101 and authentication server 105. Figures 6A to 6C and Figures 7A to 7B The image shown is transmitted from... Figure 5 The settings menu selected in the management settings screen 504 is used to display the settings.

[0086] exist Figure 6A On the login method setting screen 601 of the operation unit UI shown, the login method when logging into the operation panel can be selected. In this embodiment, user operations can be accepted and validated by selecting one or both of the options including "password authentication" using a password entered by the user and "mobile authentication (key authentication)" using a key including a public key. Furthermore, when both methods are validated on the login method setting screen 601, the login processing unit 302 can selectively display the mobile authentication screen 501 and the password authentication screen 502. In this embodiment, the password authentication button 508 is displayed on the mobile authentication screen 501, and the selection of password authentication is received. Furthermore, the mobile authentication button 509 is displayed on the password authentication screen 502, and the selection of mobile authentication is received.

[0087] In the login method settings screen 601 of the operating unit UI, if only mobile authentication is enabled, the password authentication button 508 can be hidden, and login can be performed solely via mobile authentication. In this way, all users wishing to use the MFP 101 are obligated to register their keys. Similarly, if only password authentication is enabled, the mobile authentication button 509 can be hidden, and login can be performed solely via password authentication.

[0088] Furthermore, on the login method settings screen 601 of the operation unit UI, you can select the account to log in. When a local account is selected, it is possible to use an account stored in memory. Figure 4A Accounts in the user database 401 shown for local accounts can log in to MFP 101. Furthermore, when a server account is selected, login is allowed using accounts managed in authentication server 105. In this embodiment, authentication server 105 allows login to MFP 101 using accounts managed by user management unit 323.

[0089] Password authentication provides a login method that includes entering a user ID and password. Specifically, the login processing unit 302 displays a password authentication screen 502 as a login screen on the operation panel 205. The user selects the "Authentication Destination" drop-down menu and can choose whether to use a "Local Account" or a "Server Account". "The device" in this figure indicates the use of a local account. On the login method setting screen 601 of the operation unit UI, if the use of a server account is enabled, the server name and domain name are displayed as options in the "Authentication Destination" drop-down menu. Note that the authentication destination indicates the entity performing the authentication process, and the authentication location can be selected from the "Authentication Destination" drop-down menu.

[0090] Users can use the physical or software keys (not shown) on the MFP 101 to enter their user ID and password. The login processing unit 302 receives the user ID and password input via the physical or software keys. If the "authentication destination" is "this device," it verifies whether user account information matching the received user ID and password exists in the user database 401. If matching user account information exists, the user logs in, and the login menu screen 503 is displayed.

[0091] Mobile authentication (key authentication) is performed through cooperation between the login processing unit 302, the FIDO service 304, and the authenticator 312 of the mobile terminal 102. The user is authenticated using a technology called a key, which utilizes a Public Key Infrastructure (PKI) specified by FIDO. Upon successful mobile authentication (key authentication), the mobile authentication screen 501 is displayed as a login screen on the operation panel 205, and the user is authenticated. The key registration and key-based authentication methods will be described in detail below. If user authentication using either password authentication or mobile authentication (key authentication) is successful, the login processing unit 302 logs the user into the operation panel 205.

[0092] Upon successful login, the operation unit UI service 305, which detects user login, displays menu screen 503 on the operation panel 205. Then, the operation unit UI service 305 provides functions based on user authentication. If a user with the Administrator role is already logged in, they can select "Management Settings" from menu screen 503 and access the Management Settings screen 504 to change the settings of the MFP 101. If a user with the General User role is already logged in, control is implemented to gray out the "Management Settings" button on menu screen 503, preventing it from being selected.

[0093] When "Authentication Server Settings" is selected on the management settings screen (504 error), the following message appears: Figure 7A The authentication server settings screen 701. Figure 7A The authentication server settings screen 701 is used to set up information about the authentication server with which the authentication server account communicates. For example, it registers the server name, tenant name (domain name), application ID (client ID) used in the OAuth protocol, and client key. For example, using Microsoft Entra ID, the tenant name (domain name) for each company is stored. Furthermore, on each tenant's management screen, applications used in the OAuth protocol can be registered, and client IDs and client keys can be issued. Additionally, the address of the destination for the access token associated with the client ID can be registered as a redirect URL. By registering http: / / localhost / xxxx as a redirect URL, the terminal running a browser or WebView itself can be set as the destination for receiving the access token.

[0094] When "Key Management for Server Accounts" is selected on the management settings screen (504), the following message appears: Figure 7BThe server account key management screen 702 is used to view and delete the server account configuration file information stored in HDD 204 associated with key information.

[0095] In the case of an authentication server account, the login processing unit 302 uses OAuth 2.0 Authorization Code Grant for authentication and obtains an access token from the authentication server 105. The obtained access token is used to obtain an authenticated user profile from the authentication server 105. The user profile includes basic user information such as a user ID corresponding to the user's identifier, display name, and email address. Furthermore, it is preferable to determine the "role" for MFP usage permissions for the server account based on the information included in the user profile obtained from the authentication server 105. For example, "occupation information," "role information of the authentication server 105," "user group," and "organization information" are obtained as the user profile, and the role for MFP usage permissions can be determined based on this information. For example, it is preferable to preset conversion rules for setting management positions as administrator roles and general employees as general user roles.

[0096] Now refer to Figure 8A This describes the screen transition of the operation panel 205 when using a server account for password authentication.

[0097] The login processing unit 302 uses WebView functionality to authenticate / authorize users via OAuth 2.0 authorization codes. WebView is a component with web browser functionality. Figures 8A to 8B Screens 801, 802, 803, 804, 805, and 806 are screens configured in WebView to display the HTML screen obtained from the authentication server 105.

[0098] During password authentication, the user selects "Authentication Server 105" from the "Authentication Destination" drop-down menu on the password authentication screen 502, enters a username and password, and presses the login button. The login processing unit 302 displays the WebView screen 801, accesses the authentication server 105, and obtains and displays the HTML of the authentication screen from the authentication server 105. At this time, the login processing unit 302 preferably obtains the username entered on the password authentication screen 502 and automatically sets the username on screen 801. While entering the server account, the user presses the "Next" button. Next, the WebView screen transitions to screen 802 and requests a password. The login processing unit 302 preferably obtains the password entered on the password authentication screen 502 and automatically sets the password on screen 802. While entering the server account password, the user presses the "Check-in" button on screen 802. When password authentication is successful, the screen transitions to the next screen. If multi-factor authentication for the server account is enabled, the WebView screen transitions to screen 803 and requests a code. For example, the code is a one-time password specified in RFC6238 Time-Based One-Time Password (TOTP). When the user enters the code and presses the "Verify" button, the code is verified. If the code is successfully verified, a screen requesting authorization from the user (not shown) can be displayed. When an access token granted via the authorization code is successfully obtained, the access token is used to access the REST API provided by the authentication server and obtain the user profile. The login processing unit 302 uses the obtained user profile to log the user into MFP 101 and displays menu screen 503. The login processing unit 302 transmits the user profile information to the operation unit UI service 305 and provides the MFP 101 with information about the logged-in user.

[0099] As mentioned above, in the case of MFP 101, the process of logging into MFP 101 using the password of the server account managed by authentication server 105 involves many button press operations for text input and screen transitions, which makes it very cumbersome for the user.

[0100] Now refer to Figure 8BThis describes the screen transition of the operation panel 205 when using a server account during key registration. During key registration, the user selects "Authentication Server 105" from the "Authentication Destination" dropdown menu on the key registration screen 505, enters a username and password, and presses the authentication button. The login processing unit 302 displays the WebView screen 804 and authenticates the user. When user authentication is successful via screens 804 to 806 and the access token granted via the authorization code is successfully obtained, the access token is used to access the REST API provided by the authentication server and obtain the user profile. This can be the same as described in screens 801 to 803. Next, the key registration screen 506, including a QR code, is displayed. The QR code on the key registration screen 506 includes information about the URL used for key registration, provided by the FIDO service 304.

[0101] FIDO service functions

[0102] Next, the mechanism for key registration and key authentication using FIDO Service 304 will be described. FIDO Service 304 includes web server functionality capable of communicating via HTTP. It also includes authentication functions such as WebAuthn, as specified by the FIDO Alliance or the W3C.

[0103] The FIDO service 304 is accessed via HTTPS communication from a web browser 314 of a mobile terminal 102 that has captured the QR code displayed on the mobile authentication screen 501 or the key registration screen 506. The FIDO service 304 acts as a web server, providing access to and functionality of URLs 1 through 6, as described below.

[0104] URL 1 https: / / mfp101.office.jp / registration / randomnumber

[0105] URL 1 is the URL indicating the location of the HTML used for key registration. The HTML for key registration indicated by URL 1 includes JavaScript for accessing the REST APIs described below at URLs 2 and 3. Additionally, it includes `navigator.credentials.create` as JavaScript for key generation, as specified by FIDO 2.0. Furthermore, the URL preferably includes a one-time random number. By including a random number, access can be restricted to mobile terminals of users located at a position (in front of MFP 101) where they can scan the QR code displayed on the key registration screen 506.

[0106] URL 2 https: / / mfp101.office.jp / registration / challenge

[0107] URL 2 is the URL of the REST API that indicates the location of the challenge data, which includes the random number issued by the FIDO service 304. The challenge data is used in the verification process for key registration.

[0108] URL 3 https: / / mfp101.office.jp / registration / verification

[0109] URL 3 is the URL of the REST API that receives information used for key registration. The data used for key registration includes the credential ID, challenge, public key, and digital signature issued by mobile terminal 102.

[0110] URL 4 https: / / mfp101.office.jp / authentication / randomnumber

[0111] URL 4 is the URL indicating the location of the HTML used for key authentication. The HTML for key authentication indicated by URL 4 includes JavaScript for accessing the REST APIs at URLs 5 and 6. Additionally, it includes `navigator.credentials.get`, which is the JavaScript used for key authentication as specified in WebAuthn by FIDO 2.0. Furthermore, the URL preferably includes a one-time random number.

[0112] URL 5 https: / / mfp101.office.jp / authentication / challenge

[0113] URL 5 is the URL of the REST API that indicates the location of the challenge data, which includes the random number issued by the FIDO service 304.

[0114] URL 6 https: / / mfp101.office.jp / authentication / verification

[0115] URL 6 is the URL of the REST API that receives data used for key authentication. This data includes the credential ID of the key used in the digital signature, the challenge, and the digital signature itself.

[0116] Key registration sequence

[0117] Now refer to Figure 9 Describes the sequence related to key registration. Figure 11A An example of the operation screen of mobile terminal 102 during key registration is shown. Figure 9 During the process, the operations of each step of the mobile terminal 102 are executed by the CPU 211 of the mobile terminal 102 in response to user operations and responses from the FIDO service 304. The operations of each step of the FIDO service 304 are executed by the CPU 201 of the MFP 101 in response to data reception from the mobile terminal 102.

[0118] In S901, the user runs the camera application 313 from their mobile terminal 102 and takes a picture of the QR code displayed on the key registration screen 506. In other words, the mobile terminal 102 runs the camera application according to the user's operation and takes a picture in response to the user's operation. At this time, the mobile terminal 102 can identify the QR code included in the subject image and decode the QR code.

[0119] Next, in S902, the camera application 313 runs the web browser 314. In this step, the mobile terminal 102 can run the web browser 314 in response to the URL being included in the QR code decoded in S901.

[0120] In S903, web browser 314 accesses the address of URL 1 obtained from the QR code.

[0121] In S904, the FIDO service 304 exploits... Figure 11A The HTML of screen 1101, shown for key registration, is responded to.

[0122] In S905, the mobile terminal 102 detects the pressing of the "Key Registration" button on screen 1101. The web browser 314 executes the JavaScript included in the HTML file received in S904 and accesses URL 2 in S906. Here, to save the user the effort involved in pressing the "Key Registration" button in S905, JavaScript can be executed automatically to access URL 2. This can be achieved by using a timed onload event of JavaScript being invoked when all HTML in HTML screen 1101 is loaded into the web browser 314.

[0123] The FIDO service has received a 304 error for accessing URL 2 and is generating a challenge in S907. The challenge is a random number.

[0124] Next, in S908, FIDO service 304 responds using challenge data including the generated challenge.

[0125] Next, in S909, the web browser 314 uses the received challenge data to execute navigator.credentials.create, which is JavaScript as WebAuthn, and runs the authenticator 312.

[0126] Next, in S910, the authenticator 312 authenticates the owner of the mobile terminal 102 via one of the following methods: biometric authentication such as facial or fingerprint authentication, authentication using a passcode, and pattern authentication. Figure 11A Screen 1102 is an example of a screen used to prompt for fingerprint authentication.

[0127] Next, in S911, the authenticator 312 generates a key pair (PKI private and public key pair) and a credential ID used to identify the key. This is then associated with information about the MFP 101's server (e.g., mfp101.office.jp) and the user ID, and stored in a tamper-proof storage area.

[0128] Next, in S912, the authenticator 312 uses the generated private key to digitally sign the data including the challenge data received in S908. The authenticator 312 then transmits the data used for key registration to a web browser. The generated public key, credential ID, and digital signature can be included in the data used for key registration.

[0129] Next, in S913, web browser 314 accesses URL 3 and transmits the data used for key registration to FIDO service 304.

[0130] Next, in S914, FIDO service 304 uses the challenge it issued in S907 and the public key it received to verify the digital signature.

[0131] If the digital signature verification is successful, in S915, FIDO service 304 stores the credential ID and public key as key information. In S916, FIDO service 304 responds based on whether the key registration was successful. Mobile terminal 102, having received a response indicating successful key registration, displays information such as... based on the success or failure of key registration. Figure 11A Screens such as 1103 are used to display the results to the user.

[0132] Key authentication sequence

[0133] Now refer to Figure 10 The sequence diagram describes the sequences related to key authentication. Figure 11B An example of the operation screen of the mobile terminal 102 during key authentication is shown. Figure 10 During the process, the operations of each step of the mobile terminal 102 are executed by the CPU 211 of the mobile terminal 102 in response to user operations and responses from the FIDO service 304. The operations of each step of the FIDO service 304 are executed by the CPU 201 of the MFP 101 in response to data reception from the mobile terminal 102.

[0134] In S1001, the user runs the camera application 313 from their mobile terminal and takes a picture of the QR code displayed on the operation panel 205. In other words, the mobile terminal 102 runs the camera application according to the user's operation and takes a picture in response to the user's operation. At this time, the mobile terminal 102 can sense the QR code included in the subject image and decode the QR code.

[0135] Next, in S1002, the camera application 313 runs the web browser 314. In this step, the mobile terminal 102 can run the web browser 314 in response to the URL being included in the QR code decoded in S1001.

[0136] Next, in S1003, web browser 314 accesses the address of URL 4 obtained from the QR code.

[0137] In S1004, the FIDO service 304 exploits... Figure 11B The HTML of screen 1111 shown for key authentication responds.

[0138] In S1005, the mobile terminal 102 detects the pressing of the "Key Authentication" button on screen 1111. The web browser 314 executes the JavaScript included in the HTML file received in S1004 and accesses URL 5 in S1006. Here, to save the user the effort involved in pressing the "Key Authentication" button in S1005, JavaScript can be executed automatically to access URL 5.

[0139] The FIDO service returned a 304 error upon receiving an access request for URL 5, and a challenge was generated in S1007. The challenge is a random number.

[0140] Next, in S1008, FIDO service 304 responds using challenge data including the generated challenge.

[0141] Next, in S1009, the web browser 314 uses the received challenge data to execute navigator.credentials.get as WebAuthn JavaScript as described below, and runs the authenticator 312.

[0142] Next, in S1010, the authenticator 312 authenticates the owner of the mobile terminal 102 using one of the authentication methods, including facial recognition, fingerprint recognition, passcode, and pattern recognition. Figure 11B Screen 1112 is an example of a screen used to prompt for fingerprint authentication.

[0143] Next, in S1011, the authenticator 312 obtains the key (PKI private key) stored in association with the information of the MFP 101's server (e.g., mfp101.office.jp). Then, in the challenge data received in S1008, the private key is used to generate a digital signature. The authenticator 312 transmits the data used for key authentication to a web browser. The data used for key authentication may include the digital signature and the credential ID of the key used in the digital signature, etc.

[0144] Next, in S1012, web browser 314 accesses URL 6 and transmits the data used for key authentication to FIDO service 304.

[0145] Next, in S1013, the FIDO service 304 obtains the public key associated with the received credential ID.

[0146] Next, in S1014, the digital signature included in the data received in S1012 for key authentication is verified using the challenge issued in S1007 and the public key obtained from HDD 204 in S1013. If the digital signature verification is successful, the authentication is considered successful; if the verification fails, the authentication is considered failed.

[0147] Next, in S1015, the FIDO service 304 responds based on whether the authentication was successful or failed. The mobile terminal 102, having received a response indicating successful authentication, displays information such as... based on the success or failure of the authentication. Figure 11B Screens such as 1113 are used to display the result to the user.

[0148] Next, we will refer to Figure 12 , Figure 13 and Figure 14The processing flow of the MFP 101 according to this embodiment is described. Note that in this embodiment, the process executed by the MFP 101 is stored in a software program such as the login processing unit 302 or the FIDO service 304. The software program is stored in a non-volatile storage unit such as ROM 202 or HDD 204 and is loaded into RAM 203 for use in the process to be executed by the CPU 201.

[0149] Key registration process

[0150] Figure 12 This is a flowchart illustrating the key registration process. The login processing unit 302 displays the key registration screen 505 and begins the key registration process.

[0151] In S1201, the login processing unit 302 obtains the authentication destination selected on the key registration screen 505. Next, in S1202, the login processing unit 302 determines whether the account being registered as the key is a local account or a server account based on the authentication destination. If the authentication destination is "the device," it is determined to be a local account. If the authentication destination is a server name or domain name, it is determined to be a server account.

[0152] In the case of a local account, in S1203, the login processing unit 302 refers to the username and password entered on the key registration screen 505 and the... Figure 4A The system displays the username and password registered in the user database 401 for the local account. If these two match, authentication is successful. If either does not match, authentication fails. This is how users are authenticated.

[0153] Upon successful authentication, in S1204, the FIDO service 304 displays a key registration screen 506 including a QR code and receives the key registration. During execution... Figure 9 If the sequence shown exists and there is key registration from mobile terminal 102, FIDO service 304 notifies login processing unit 302 of the key information (credential ID and public key) obtained from mobile terminal 102.

[0154] In S1205, the login processing unit 302 associates the key information (credential ID and public key) with the user authenticated in S1203 and stores it in the user database for local accounts. Note that, as described above, the user database 401 includes items constituting the user profile in a manner similar to the user profile table 403. Therefore, in S1205, the step of storing the obtained key information in association with the user profile can also be performed.

[0155] In the case of a server account, in S1206, the login processing unit 302 displays screens 801 to 803, communicates with the authentication server 105, authenticates the user, and obtains an access token and a refresh token.

[0156] Next, in S1207, the login processing unit 302 communicates with the authentication server 105 via the server communication unit 303 using an access token and obtains the user profile of the authenticated user.

[0157] Upon successful acquisition of the user profile, in S1208, the FIDO service 304 displays the key registration screen 506, including the QR code, and receives the key registration. During execution... Figure 9 If the sequence shown exists and there is key registration from mobile terminal 102, FIDO service 304 notifies login processing unit 302 of the key information (credential ID and public key) obtained from mobile terminal 102.

[0158] In S1209, the login processing unit 302 associates the key information with the user profile obtained in S1207 and stores it in HDD 204. The user profile to be stored can be an unchanged user profile obtained from the server, or it can be information that has been edited or transformed to facilitate processing in MFP 101. For example, as a user profile from authentication server 105, if it includes occupational information, the occupational information is converted into role information and stored, etc. For example, it is preferable to be able to preset conversion rules for setting management positions as administrator roles and general employees as general user roles.

[0159] Furthermore, in S1210, the login processing unit 302 preferably associates the access token and refresh token obtained in S1206 with the key (public key) and stores them.

[0160] When the key registration is completed, the login processing unit 302 displays "Key registration complete" and "Process ends" on screen 507.

[0161] The user profiles for the server accounts stored in HDD 204 can be accessed by the administrator of MFP 101 via... Figure 7B The server account key management screen 702 shown can be viewed or deleted at any time. When an administrator selects a user profile on the server account key management screen 702 and presses the "Delete" button, the selected user profile is deleted. Deleted information includes data such as key information, user profiles stored in association with the key information, access tokens, and refresh tokens, and this information is removed from HDD 204.

[0162] Key authentication process

[0163] Figure 13 This is a flowchart illustrating the key authentication process.

[0164] In S1301, the login processing unit 302 displays the mobile authentication screen 501 and receives the authentication key. Execution Figure 10 The sequence is shown, and FIDO service 304 receives data for key authentication from mobile terminal 102. When the credential ID included in the data for key authentication is obtained, in S1302, FIDO service 304 searches for and obtains the public key corresponding to the credential ID from HDD 204.

[0165] In S1303, FIDO service 304 uses the public key obtained from HDD 204 to verify the digital signature included in the data used for key authentication and determines whether the verification is successful. If the verification is successful, key authentication is considered successful. If obtaining the public key or verifying the digital signature fails, key authentication is considered unsuccessful. If key authentication is considered unsuccessful, in S1311, authentication failure is displayed on the mobile authentication screen 501, and the process ends.

[0166] If key authentication is successful, in S1304, the login processing unit 302 determines the type of account associated with the obtained public key. Figure 4A If a public key is found in the user database used for local accounts, it is determined to be a local account. If the obtained public key is associated with a user profile obtained from the server, it is determined to be a server account.

[0167] In the case of a local account, in S1305, the login processing unit 302 obtains the user information associated with the public key from the user database used for local accounts.

[0168] Next, in S1309, the login processing unit 302 uses the obtained user information to perform login processing, logs the authenticated user into MFP 101, and displays the menu screen 503.

[0169] In the case of a server account, in S1306, the login processing unit 302 obtains the user profile stored in association with the key.

[0170] Next, in S1307, the login processing unit 302 uses the access token and refresh token stored in association with the key information, and connects to the authentication server 105 to attempt to obtain the latest user profile. If the latest user profile is successfully obtained, the stored user profile is updated with the new information.

[0171] In S1308, the login processing unit 302 determines whether the server account is valid. If the latest user profile is successfully obtained from the authentication server 105 and the server account can be confirmed to be valid, the server account is determined to be valid. If the server account has been deleted from the authentication server 105 or can be confirmed from the latest user profile to be deactivated, the server account is determined to be invalid.

[0172] If the server account is deemed valid, in S1309, the login processing unit 302 uses the user profile stored in association with the key information to perform login processing, logs the authenticated user into MFP 101, and displays the menu screen 503.

[0173] If the server account is determined to be invalid, in S1310, the login processing unit 302 deletes the stored key information and user configuration file.

[0174] In addition, in S1311, the login processing unit 302 displays "Authentication failed" on the mobile authentication screen 501 and ends the processing.

[0175] In the above process example, in S1307 and S1308, verification related to obtaining the latest user profile of authentication server 105 and the validity of the server account is performed. However, this process can be omitted, and in S1306, if the user profile stored with the key information can be found, the login process in S1309 can be performed using that user profile.

[0176] The following methods are valid alternatives to updating user profiles stored in association with key information.

[0177] User profile synchronization process

[0178] Figure 14 This is a flowchart illustrating the process for synchronizing the "user profile stored in association with key information" and the "user profile of authentication server 105". Figure 14 The processing is achieved by executing the program loaded into RAM 203 via the CPU 201 of the MFP 101. However, in the description, Figure 3 The software modules (and particularly the server communication unit 303) are execution entities. For example, they can be executed periodically. Figure 14 The processing.

[0179] The server communication unit 303 of the MFP 101 begins a user profile update processing task at a predetermined time. This task can be a task executed on a predetermined date and time or a task executed periodically (such as once every 24 hours).

[0180] When processing begins, in S1401, server communication unit 303 accesses authentication server 105 and obtains user profiles for multiple server accounts managed by authentication server 105. For example, if authentication server 105 uses Microsoft Entra ID, access tokens can be obtained using OAuth 2.0 Client Credential Grant, using application credentials (client ID, client key, and digital signature, etc.) pre-stored in MFP 101. Furthermore, in the Microsoft Entra ID side settings, if access permissions for user information associated with the client ID are granted, user profiles for multiple server accounts can be obtained using access tokens. Additionally, if authentication server 105 uses Google Workspace, a mechanism is prepared for privileged accounts referred to as service accounts, and access tokens can be obtained using the service account's credential information.

[0181] Next, in S1402, the server communication unit 303 compares the user profiles of the multiple server accounts obtained in S1401 with the user profiles stored in association with key information. If there are updates to the information, the user profiles are updated with the new information.

[0182] Next, in S1403, if the server communication unit 303 learns from the information obtained in S1401 that the server account has been deleted or invalidated, the server communication unit 303 deletes the corresponding user profile.

[0183] In this way, the user profile stored in MFP 101 with associated key information can be synchronized with the user profile of authentication server 105.

[0184] The effect of this embodiment

[0185] As described above in the first embodiment, the process of logging into the MFP 101 using a password for a server account involves numerous button presses for text input and screen transitions, which is quite cumbersome for the user. However, by obtaining the user profile required to log into the MFP from the authentication server and storing the user profile along with key information, key authentication can be used instead of password authentication.

[0186] As described in this embodiment, key-based authentication allows for authentication on a user's mobile device using a process that includes simply scanning a QR code and performing biometric authentication, thereby minimizing effort such as button presses. Since key-based authentication is a highly secure multi-factor authentication method resistant to phishing, user-friendliness is enhanced without compromising security.

[0187] In this embodiment, the FIDO service and the authentication server are configured separately. Therefore, even if the authentication server used by the user does not support the FIDO server, the FIDO mechanism can be used alone.

[0188] Furthermore, the key information is configured to be stored in the MFP instead of the authentication server. Therefore, the authentication server does not need to have key registration functionality.

[0189] Furthermore, even if an authentication server has FIDO service functionality and the ability to perform key authentication, it cannot be guaranteed that it will be operated to use key authentication. In this embodiment, the login method settings for the MFP's operating unit UI can be limited to mobile authentication (key authentication). Therefore, even if no key-using operation is performed on the authentication server side, key-using can be forced for logging into the MFP.

[0190] It also describes the process for updating user profiles stored in the MFP, taking into account updates, deletions, and invalidations of server account information on the authentication server side.

[0191] Second Embodiment

[0192] In the first embodiment described above, the image forming apparatus includes a digital signature verification technology (FIDO service). In this example, where multiple image forming apparatuses are placed in an office and a user uses multiple image forming apparatuses, it is necessary to register key information (public key, etc.) in each image forming apparatus. As an embodiment to solve this problem, in the second embodiment described below, the digital signature verification technology (FIDO service) is configured externally to the image forming apparatus. In the second embodiment, the externally configured digital signature verification technology (FIDO service) is used to authenticate users using the image forming apparatus.

[0193] System Configuration

[0194] Now refer to Figure 15The system configuration described in this embodiment is similar to that of the MFP 101, mobile terminal 102, authentication server 105, and connection method in the first embodiment. However, in this second embodiment, the FIDO server 106 is connected via a network. The FIDO server 106 may be a virtual server established in a cloud connected via the Internet, or it may be a field server connected to LAN 104. Although not shown, multiple MFPs with the same configuration as the network-connected MFP 101 may exist in an office.

[0195] Hardware configuration

[0196] The hardware configuration of the MFP 101 is similar to that of the first embodiment. Figure 2A The configuration shown is similar to that of the first embodiment. The hardware configuration of the mobile terminal 102 is similar. Figure 2B The configuration shown.

[0197] Figure 16 This is a simplified diagram showing the hardware configuration of a general-purpose computer used to implement the FIDO server 106.

[0198] The CPU 1601 executes programs stored in the ROM 1602 and programs such as operating systems (OS) and applications loaded from external storage unit 1610 into RAM 1603. In other words, the CPU 1601 serves as a processing unit that executes the various sequences described below by executing programs stored in a readable storage medium. RAM 1603 is the main memory of the CPU 1601 and is used as a working area, etc. The keyboard controller 1604 controls operation input from the keyboard 1608 or an indicating device (mouse, touchpad, touch panel, or trackball, etc.) not shown. The display controller 1605 controls the display of the display 1609. The disk controller 1606 controls disk access to the storage unit 1610, such as a hard disk drive (HDD) or flash memory, which stores various types of data. The communication unit 1607 is connected to a network and is a network interface that performs communication control processing with other devices connected to the network. In the case of establishing a server as a virtual server, since the operation is performed remotely, the keyboard 1608 and the display 1609 are not necessarily required. Alternatively, instead of storage unit 1610, a storage unit that supports a network capable of communicating with communication unit 1607 can be used.

[0199] Software Configuration

[0200] Figure 17 This is a simplified diagram illustrating the software configuration of MFP 101, mobile terminal 102, authentication server 105, and FIDO server 106. (Compared to the first embodiment) Figure 3The same software modules shown are given the same reference numerals and are not described.

[0201] replace Figure 3 The FIDO service 304 shown, the operation unit login service 301 communicates with the FIDO server 106 via the server communication unit 303.

[0202] Server communication unit 303 receives messages from FIDO server 106, thereby establishing a WebSocket connection with MFP management service 332 of FIDO server 106. The connection with MFP management service 332 is not limited to using WebSocket, and any technology that enables messages to be transmitted from FIDO server 106 to MFP can be used. For example, other technologies such as Message Queuing Telemetry Transport (MQTT), long polling, and WebPush can be used.

[0203] The MFP management service 332 of the FIDO server 106 can manage information about multiple MFPs connected to the FIDO server 106. The MFP management service 332 uses client certificate technology and the like to authenticate the multiple MFPs connected to the FIDO server 106. In addition, it receives IDs for identifying MFPs from the server communication unit 303 and manages the connection between the FIDO server 106 and the MFPs.

[0204] FIDO service 331 includes web server functionality capable of communicating via HTTP. It also includes authentication functionality such as WebAuthn, specified by the FIDO Alliance or W3C. Furthermore, FIDO service 331 is configured with a website for administrators of FIDO server 106 to configure settings. For example, to register information for collaboration with authentication server 105, as shown in screen 701, a website is included for registering information such as server name, tenant name (domain name), application ID, and client key. Additionally, FIDO service 331 stores user profiles and key information obtained from authentication server 105 in association. Therefore, a website similar to that in screen 702 is configured for viewing and deleting databases storing information similar to that in user profile table 403, stored key information, and user profiles.

[0205] MFP Management Service 332 is configured with websites or databases for registering or managing MFPs connected to FIDO Server 106.

[0206] FIDO server 106 can be configured to manage the key information and configuration files of MFPs and MFP users in each office on a tenant-by-tenant basis, based on contracts with the company office. In this configuration, only users with authorized permissions at the tenant level can register with authentication server 105 on the FIDO server 106 website and manage the keys and configuration files of MFPs and MFP users.

[0207] For simplicity, the MFP 101 according to this embodiment is configured such that only "Mobile Authentication (Key Authentication)" is selected and "Password Authentication" is set to OFF in the login method setting screen 601 of the operation unit UI. Furthermore, for the login account, only "Server Account" is selected, and the setting for using a local account is set to OFF.

[0208] Figure 18 This is a simplified diagram showing the login screen displayed on the operation panel 205 based on this setting and the menu screen displayed after login.

[0209] The FIDO server setup screen 1805 is used to enable / disable the MFP 101's use of the FIDO server 106 and to register information about the FIDO server 106. Furthermore, the FIDO server setup screen 1805 provides functions such as ID registration for MFP identification, client certificate issuance for the FIDO server to identify MFPs, and certificate import / export. The FIDO server setup screen 1805 is displayed when "FIDO Server Settings" is selected on the management setup screen 1804.

[0210] Mobile authentication screen 1801 displays a QR code for key authentication. The URL for key authentication, provided by FIDO server 106, is stored in the QR code. Additionally, a random number can be included in the URL. The random number is issued by MFP 101 or FIDO server 106, and the random number information is shared in advance through server communication unit 303 of MFP 101 and MFP management service 332. MFP management service 332 associates and manages the random number with the MFP's ID and connection information in a way that makes it easy to know which random number is associated with which MFP.

[0211] Mobile authentication screen 1801 displays a "Key Registration" button 510. When the "Key Registration" button 510 is pressed, key registration screen 1802 is displayed. A QR code for key registration is displayed on key registration screen 1802. The URL for key registration provided by FIDO server 106 is stored in the QR code. When authentication is successful via mobile authentication screen 1801, menu screen 1803 is displayed. When management settings are selected on menu screen 1803, management settings screen 1804 is displayed.

[0212] Key registration process

[0213] Next, we will refer to Figure 19 The key registration process according to the second embodiment is described. Figure 19 This is a flowchart illustrating the key registration process. Unless otherwise stated, the following steps will be performed: Figure 19 The entity representing the process flow shown is the CPU 1601 of the FIDO server 106. Figure 20 This is a diagram showing the screen transition on the mobile terminal 102 during key registration.

[0214] The user uses the camera function of their mobile terminal 102 to capture a QR code displayed on the key registration screen 1802, runs a web browser 314, and accesses the URL for key registration provided by the FIDO server 106. The FIDO service 331 of the FIDO server 106 initiates key registration by detecting access to the URL for key registration. Having detected access to the URL for key registration, the FIDO service 331 responds to the mobile terminal 102 using HTML of the UI, including the "Authenticate with Authentication Server 105" button on screen 2001. The FIDO service 331 detects the pressing of the "Authenticate with Authentication Server 105" button on screen 2001. Figure 19 The processing begins at this stage.

[0215] In S1901, FIDO service 331 redirects the access request to the URL of authentication server 105 for user authentication / authorization via an OAuth 2.0 authorization code. To eliminate the effort required for the user to press the "Authenticate with authentication server 105" button, upon detecting access to the URL used for key registration, the access request can be redirected to the URL of authentication server 105 instead of responding with an HTML screen.

[0216] The user authentication screen 2002, provided by the authentication server 105, is displayed on the mobile terminal 102. The user enters their user ID and password for the server account on the user authentication screen 2002. Additionally, to enable multi-factor authentication, an additional one-time password (not shown) can be requested. Upon successful user authentication, an OAuth 2.0 authorization screen (not shown) can be displayed. Upon successful authentication / authorization, the access token and refresh token are transmitted to the FIDO service 331.

[0217] In S1902, as a result of authentication / authorization, FIDO service 331 obtains an access token and a refresh token.

[0218] Next, in S1903, FIDO service 331 uses the obtained access token to access the REST API provided by authentication server 105 and obtains the user profile of the authenticated server account.

[0219] Next, in S1904, in response to receiving the access token, FIDO service 331 transmits HTML of screen 2003, including a "Key Registration" button and JavaScript for WebAuthn, to mobile terminal 102, and receives the key registration. When a press of the "Key Registration" button is detected, JavaScript is executed, and the key registration sequence begins. To save the user the effort involved in pressing the "Key Registration" button, JavaScript can be executed automatically to begin the key registration sequence. The key registration sequence includes the execution of JavaScript between mobile terminal 102 and FIDO service 331. Figure 9 The processing between mobile terminal 102 and FIDO service 304 in S903 to S916 is similar. During this period, a screen 2003 requesting the user to perform biometric authentication is displayed on mobile terminal 102.

[0220] In S1905, in response to the successful key registration sequence, FIDO service 331 associates the obtained key information (credential ID and public key) with the user profile obtained in S1903 and stores them in a database for storing information similar to that in user profile table 403.

[0221] Furthermore, in S1906, FIDO service 331 preferably stores the access token and refresh token obtained in S1902 in association with key information.

[0222] Key authentication process

[0223] Next, we will refer to Figure 21 The key authentication process according to the second embodiment is described. Figure 21This is a flowchart illustrating the key authentication process. Unless otherwise specified, execution... Figure 21 The entity representing the process flow shown is the CPU 1601 of the FIDO server 106.

[0224] After the server communication unit 303 of MFP 101 and the MFP management service 332 communicate in advance and share a random number, in S2101, the FIDO service 331 begins receiving key authentication. The user uses the camera function of their mobile terminal 102 to capture a QR code displayed on the mobile authentication screen 1801, runs a web browser 314, and accesses the URL for key authentication provided by the FIDO server 106. The URL for key authentication includes a random number. By confirming in advance that the random number matches the one shared by MFP 101, the FIDO service 331 can determine that the key authentication request is a request to log in to MFP 101. If the random number included in the URL does not match the random number shared by any of the multiple MFPs, it is preferably determined that unauthorized access has occurred, and the key authentication fails.

[0225] The key authentication sequence includes performing a connection between the mobile terminal 102 and the FIDO service 331. Figure 10 The processing between the mobile terminal 102 and the FIDO service 304 in S1001 to S1012 shown is similar.

[0226] In S2102, FIDO service 331 receives data (credential ID, challenge, and digital signature, etc.) for key authentication from mobile terminal 102. It searches the database storing keys and obtains key information (public key) corresponding to the credential ID obtained from the data used for key authentication.

[0227] If the key is successfully obtained, in S2103, FIDO service 331 uses the public key to verify the digital signature, performs key authentication, and determines the result. If the key information (public key) corresponding to the credential ID is not in the database or the digital signature verification fails, the key authentication is deemed unsuccessful. In the case of unsuccessful key authentication, in S2109, the MFP 101 connected via WebSocket is notified of the unsuccessful key authentication, and the process ends.

[0228] In S2103, if the verification of the digital signature using the public key is successful, the key authentication is considered successful. In this case, the process proceeds to S2104.

[0229] Next, in S2104, FIDO service 331 obtains the user profile of the server account stored in association with the successfully authenticated key information.

[0230] Next, in S2105, FIDO service 331 uses the access token and refresh token stored in association with the key information and connects to authentication server 105 to attempt to obtain the latest user profile. If the latest user profile is successfully obtained, the stored user profile is updated with the new information.

[0231] In S2106, FIDO service 331 determines whether a server account is valid. If the latest user profile is successfully obtained from authentication server 105 and the server account can be confirmed to be valid, the server account is considered valid. If the server account has been deleted from authentication server 105 or can be confirmed from the latest user profile to be deactivated, the server account is considered invalid.

[0232] If the server account is deemed valid, in S2107, FIDO service 331 transmits the user profile stored in association with the key information to MFP 101 connected via WebSocket.

[0233] If the server account is determined to be invalid, in S2108, FIDO service 331 deletes the stored key information and user profile. Furthermore, in S2109, FIDO service 331 notifies MFP 101, connected via WebSocket, that key authentication failed, and the process ends.

[0234] The MFP 101, which has received the user profile of the server account from the FIDO server 106, uses the received user profile to perform login processing, logs the authenticated user into the MFP 101, and displays the menu screen 503.

[0235] In the above process example, in S2105 and S2106, verification related to obtaining the latest user profile of authentication server 105 and the validity of the server account is performed. However, this process can be omitted, and in S2104, if the user profile stored with the key information can be found, the login process in S2107 can be performed using that user profile.

[0236] User profile synchronization

[0237] The following methods are valid as alternatives to updating the user profile stored in association with key information on the FIDO server 106.

[0238] and Figure 14The process shown is similar to that performed by the FIDO server 106 to update user profiles. Specifically, preferably, the FIDO server 106 pre-registers information and credentials for accessing the authentication server 105, periodically obtains user profiles for multiple server accounts from the authentication server 105, and updates its stored user profiles. Furthermore, if it is known that a server account has been deleted or invalidated, the corresponding user profile is deleted.

[0239] Effects of the second embodiment

[0240] In addition to the effects of the first embodiment, the second embodiment also has the following effects.

[0241] In the first embodiment, when multiple MFPs exist in an office, key information (public key, etc.) needs to be registered in each MFP. To solve this problem, in the second embodiment described above, the FIDO server that collaborates with the MFPs is configured separately from the MFPs and the authentication server. Therefore, by registering the key once in the FIDO server, the same key can be used to log in to multiple MFPs that collaborate with the FIDO server.

[0242] Other embodiments

[0243] In the first and second embodiments described above, the OAuth 2.0 mechanism is used to perform authentication / authorization of the server account and obtain the user profile of the server account. As an example of a mechanism other than OAuth 2.0, the mechanism specified in SAML 2.0 can be used for user authentication and user profile acquisition. The techniques disclosed herein are not limited to user authentication methods and user profile acquisition methods for server accounts.

[0244] Other embodiments

[0245] Embodiments of the present invention can also be implemented by providing software (including computer program products of computer programs) that performs the functions of the above embodiments to a system or device via a network or various storage media, and the computer (central processing unit (CPU) or microprocessor unit (MPU) of the system or device) reads and executes the computer program.

[0246] While this disclosure has been described with reference to embodiments, it should be understood that this disclosure is not limited to the disclosed embodiments. The scope of the appended claims should be given the broadest interpretation to cover all such modifications and equivalent structures and functions.

Claims

1. An image forming apparatus, comprising: A storage component is used to store a public key and a user's user profile in memory, the public key being obtained from the user's terminal and paired with a private key held in the terminal. A first authentication component is configured to perform a first authentication, which authenticates the user by verifying a digital signature received from the terminal using the public key. A login component is configured to allow the user to log in to the image forming device using the user profile stored in association with the public key, provided that the user has been successfully authenticated via the first authentication.

2. The image forming apparatus according to claim 1, further comprising: A second authentication component is used to perform a second authentication using an authentication server connected to the image forming device. This second authentication is used to authenticate the user using authentication information received from the user's terminal. The obtaining component is used to obtain from the authentication server the user profile of the user authenticated through the second authentication, and A first registration component is used to store the user profile obtained from the authentication server and the public key obtained from the terminal in association in the memory.

3. The image forming apparatus according to claim 2, further comprising: A component for obtaining an access token from an authentication server connected to the image forming device, wherein, The storage component stores the access token and the public key in association with each other, and If the user is successfully authenticated in the first authentication process via verification using a public key with a digital signature received from the terminal, the obtaining component uses an access token stored in association with the public key to obtain the user's user profile from the authentication server.

4. The image forming apparatus according to claim 3, further comprising: The determination component is used to, if the authentication of the user is successful using the digital signature verification in the second authentication component, access the authentication server using an access token stored in association with the public key, and determine the validity of the user's user profile. If the login component determines that the user profile is valid during the determination process, it allows the user to log in to the image forming device using the user profile.

5. The image forming apparatus according to claim 4, further comprising: A component for deleting the public key and the user's user profile stored by the storage component when the judgment component determines that the user profile is invalid.

6. The image forming apparatus according to claim 1, wherein, The storage component stores authentication information associated with the user, and The image forming apparatus further includes: A third authentication component is configured to perform a third authentication when local account authentication is selected. This third authentication is used to authenticate the user by comparing the authentication information with authentication information received from the user's terminal. The second registration component is used to store the user profile and the public key obtained from the terminal in the memory in association if the authentication in the third authentication is successful.

7. A server device connected via a network to an image forming apparatus, the server device comprising: The fourth authentication component is used to perform a fourth authentication, which is used to authenticate a user using an authentication server; The obtaining component is used to obtain, from the authentication server, the user profile of the user authenticated by the fourth authentication; A registration component is used to store a public key and the user's user profile in a storage component, the public key being obtained from the user's terminal and paired with a private key stored in the terminal. A fifth authentication component is configured to perform a fifth authentication, which authenticates the user by verifying a digital signature received from the terminal using the public key. A transmission component, configured to transmit a user profile stored in association with the public key to the image forming device if authentication in the fifth authentication is successful.

8. The server device according to claim 7, wherein, The fourth authentication component obtains the access token of the authenticated user from the authentication server. The registration component stores the public key and the access token in association in the storage component, and If the obtaining component successfully completes the fifth authentication, it obtains the user profile from the authentication server using an access token stored in association with the public key.

9. The server device according to claim 8, further comprising: The determination component, in the event of successful authentication in the fifth authentication, uses an access token stored in association with the public key to access the authentication server, and determines the validity of the user profile of the user authenticated in the fifth authentication. If the transmission component determines that the user profile is valid in the determination process, it transmits the user profile to the image forming device.

10. The server device according to claim 9, further comprising: A component for deleting the public key and the user's user profile stored in the storage component if the user profile is determined to be invalid in the determination process.

11. A method for controlling an image forming apparatus, the image forming apparatus including a memory for storing a public key and a user profile associated with each other, the public key being obtained from the user's terminal and paired with a private key held in the terminal, the control method comprising: Perform a first authentication, which is used to authenticate the user by verifying the digital signature received from the terminal using the public key; as well as If the user is successfully authenticated in the first authentication, the user is allowed to log in to the image forming device using the user profile stored in association with the public key.

12. The control method for the image forming apparatus according to claim 11, further comprising: A second authentication is performed using an authentication server connected to the image forming device, the second authentication being used to authenticate the user using authentication information received from the user's terminal; Obtain the user profile of the user who has been authenticated by the second authentication from the authentication server; as well as The user profile obtained from the authentication server and the public key obtained from the terminal are stored in the memory in association with each other.

13. The control method for the image forming apparatus according to claim 11, wherein, The memory stores authentication information associated with the user, and The control method for the image forming apparatus further includes: If authentication using a local account is selected, a third authentication is performed, which authenticates the user by comparing the authentication information with authentication information received from the user's terminal. If authentication in the third authentication is successful, the user profile and the public key obtained from the terminal are stored in the memory in association with each other.

14. A method for controlling a server device connected to an image forming device via a network, the control method comprising: Perform a fourth authentication, which is used to authenticate the user using an authentication server; Obtain the user profile of the user who has been authenticated through the fourth authentication from the authentication server; The public key and the user's user profile are stored in memory in association with each other. The public key is obtained from the user's terminal and is paired with the private key held in the terminal. Perform a fifth authentication, which is used to authenticate the user by verifying the digital signature received from the terminal using the public key; as well as If authentication in the fifth authentication is successful, the user profile stored in association with the public key is transmitted to the image forming device.

15. A computer program product comprising a program that, when executed by a computer, implements the steps of the method according to any one of claims 11 to 14.

16. A non-transitory computer-readable storage medium storing a program that, when executed by a computer, implements the steps of the method according to any one of claims 11 to 14.

Images