JP4873898B2 - Web authentication method and web authentication server - Google Patents

Description

  The present invention makes it possible to change a user using a session object and share authentication information among a plurality of processes even when a plurality of web applications that operate in a plurality of processes are implemented in one web application. A web authentication method and a web authentication server are provided.

  In recent years, various information has been displayed as Web pages on a Web browser of a client PC connected via a network such as the Internet. Many types of information cannot be provided to all users who access indiscriminately. Accordingly, it has been controlled to authenticate a user before providing such information and to provide information only when the authentication is successful.

  As described above, an authentication method has been proposed in which network connection with a client PC is permitted only when authentication is successful, and predetermined information is provided as a Web page according to the authentication result (for example, Patent Document 1).

Also, an authentication method has been proposed in which control is performed so as to change information provided according to the authority level of the authenticated user (for example, Patent Document 2).
JP 2002-157219 A JP 2002-108870 A

  However, in the above conventional authentication method, when a user has registered with multiple user names, he / she cannot authenticate with other user names and receive information without interrupting the network connection. There was a problem.

  This problem will be described in detail with reference to FIGS. The conventional authentication method as shown in FIGS. 1 and 2 has a problem that even if an attempt is made to switch a user from an authenticated Web screen, the user cannot be authenticated by the switched user.

  In FIG. 1, when a user using the Web browser of the client PC 1 makes initial access to a device, the device authentication module 5 is called by, for example, calling login.cgi to log in, and authentication NG By returning (401 error) to the client PC 1 as a response to the login, a predetermined authentication screen (basic authentication screen) is displayed on the client PC 1. When the user inputs a user name (account) and a password as authentication information, authentication is performed by the authentication module 5 and authentication OK (authentication successful) is notified to the Web page library 4 in order to display the top page. Is done. The web page library 4 calls a web page function (WPF) 6 for displaying a top page by a predetermined web application 7 and provides the top page to the client PC 1 as a response to the authentication created by the web application 7.

  At the time of this authentication, the Web browser of the client PC 1 stores the URL at the time of authentication and authentication information (user name and password). Thereafter, when a request is transmitted to the authenticated URL, the user name and password used at the time of authentication and the request header are set, so that authentication information is automatically passed to the device.

  After the top page is displayed, when the user clicks the user switching button to change the user (for example, change to another user name), the Web browser of the client PC 1 displays the authenticated user name and password. It will be sent automatically. As a result, even though the user tried to authenticate with a different user name, the top page with the already authenticated user name and password was again provided without authenticating with a different user name. It was.

  Therefore, the user must close and restart the Web browser to access the device and perform authentication with a different user name, and cannot change the user from the top page after authentication. When using the Web application 7 that is frequently changed by the user, it is difficult for the user to use.

  There is a conventional authentication method that solves the conventional authentication method shown in FIG. 1 and enables transition between a plurality of pages in the same Web application 7 and also allows a user to change. As shown in FIG. 2, in this conventional authentication method, a session is created only when the authentication is successful (that is, a session is uniquely created for the web browser of the client PC 1), and the web browser of the client PC 1 and In order to manage connections, user information including authentication information is shared between pages.

  When the user requests a user change, the created session is discarded and the Web application 7 displays a basic authentication screen on the client PC 1 by transmitting a 401 error. As a result, the user can change the user by using a different user name (another account) and a password.

  In the conventional authentication method shown in FIG. 2, each Web page function 6 starts up a plurality of processes, and creates one session for the Web browser for each process, thereby realizing the authentication method. On the device side, even if the user substantially ends the session by closing the web browser, etc., the information cannot be obtained, so the session is discarded due to timeout so that the session does not remain as it is. Was in control.

  However, when a plurality of Web applications that operate in different processes are combined and implemented as one Web application, session management is performed only for one process. Cannot be shared between. When straddling a plurality of Web applications, authentication must be performed each time.

  In addition, the user can be changed by managing the session in each process. However, in the case of a web application that operates in one process on one web page, every time the web page transitions. User authentication will be performed. Furthermore, when managing a session after authentication, if the number of connected users increases, storage areas corresponding to the number of users are required.

  In order to reduce the area for managing unnecessary sessions that occur because the end of the Web browser of the client PC 1 cannot be grasped, a timer is set and an expiration date is set. If the user authentication cannot be performed, the user has to input the authentication information many times.

  Therefore, the problem of the present invention is that even when a plurality of Web applications that operate in a plurality of processes are implemented in one Web application, the user can be changed using a session object, and authentication information is transferred between a plurality of processes. It is to provide a web authentication method and a web authentication server that can be shared with each other.

In order to solve the above-mentioned problems, the present invention displays a basic authentication screen that allows a user to input authentication information to a browser of a client PC connected via a network, as described in claim 1, In the web authentication server that authenticates the user by using the header information of the request in which the authentication information that has been input is set, a receiving unit that receives the request transmitted from the browser, and the request requests authentication, Generating means for generating a session object for managing a session with the browser; display means for displaying the basic authentication screen on the browser; and the user based on the authentication information input from the basic authentication screen. Authentication means for authentication, and if the authentication is successful, the session Configured to have a discarding discarding means the emission object.

In such a web authentication server , since a session object is generated when the request requires authentication, there is no need to manage the session object in association with individual processes or web applications. Accordingly, the authentication process is not performed depending on individual processes or Web applications. In other words, the authentication process is shared by all processes and Web applications. Further, since the session object is discarded when the authentication is successful, the lifetime of the session object can be shortened. Therefore, the area for the session object can be used effectively.

Further, the present invention is as described in claim 2, wherein if the authentication by the authentication hand stage is successful, the page information generation means to generate page information to be displayed on the page specified in the request, the it is possible to configure the page information generated by the page information generation means so as to further have a conversion means to convert into a displayable format in the browser.

In such a web authentication server , page information is generated after authentication, and information can be provided by converting it into a format such as HTML, for example.

Furthermore, the present invention is, as described in claim 3, said discarding hand stage may be configured to discard the session object has timed out.

Such a web authentication server can prevent the generated session object from being unnecessarily managed. The area for the session object can be used effectively.

Further, the present invention is as described in claim 4, when the page transition by said request, to suppress the execution of the generated hand stage and the display hand stage, configured to execute the authentication hand stage directly can do.

In such a web authentication server , a session object is not generated in the case of page transition. Therefore, the authentication process is directly performed without performing authentication corresponding to the session, so that the session object area is not wasted. Further, authentication by page transition can be performed without depending on individual processes or Web applications.

  According to the present invention, since the session object is generated when the request requires authentication, there is no need to manage the session object in association with individual processes or Web applications. Accordingly, the authentication process is not performed depending on individual processes or Web applications. In other words, the authentication process is shared by all processes and Web applications.

  Further, when the authentication is successful, the generated session object is discarded, so that the lifetime of the session object can be shortened. Therefore, the area for the session object can be used effectively.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[First embodiment]
The information processing apparatus according to the first embodiment of the present invention has at least one of a plurality of different image forming functions such as a printer, a FAX, and a copy, and can provide information related to image formation by a plurality of Web applications. This device functions as a simple Web server.

  FIG. 3 is a block diagram showing a hardware configuration of the information processing apparatus according to the first embodiment of the present invention. In FIG. 3, an information processing apparatus 100 is an apparatus controlled by a computer, and includes a CPU (Central Processing Unit) 11, a ROM (Read-Only Memory) 12, a RAM (Random Access Memory) 13, and a nonvolatile memory. RAM (non-volatile random access memory) 14, real-time clock 15, Ethernet (registered trademark) I / F (Ethernet (registered trademark) Interface) 21, USB (Universal Serial Bus) 22, IEEE (Institute of Electrical and Electronics Engineers) 1284 23, a hard disk I / F 24, an engine I / F 25, an RS-232C I / F 26, and a driver 27, which are connected to the system bus B. The information processing apparatus 100 operates as a server computer.

  The CPU 11 controls the information processing apparatus 100 according to a program stored in the ROM 12. In the RAM 13, for example, areas are allocated to resources connected to the interfaces 21 to 26. The nonvolatile RAM 14 stores information necessary for processing by the CPU 11 to control the information processing apparatus 100. The real-time clock 15 measures the current time and is used by the CPU 11 to synchronize processing.

  An Ethernet (registered trademark) interface cable such as 10BASE-T or 100BASE-TX is connected to the Ethernet (registered trademark) I / F 21. A USB interface cable is connected to the USB 22. An IEEE1284 interface cable is connected to the IEEE1284 23.

  A hard disk 34 is connected to the hard disk I / F 24, and document data of a document to be printed or image data after print processing transmitted via the network is stored in the hard disk 34 via the hard disk I / F 24. . Connected to the engine I / F 25 are a plotter 35-1 for printing on a predetermined medium based on document data, a scanner 35-2 for capturing image data, and the like. An operation panel 36 is connected to the RS-232C I / F 26 to display information to the user and acquire input information or setting information from the user.

  A program related to processing performed in the information processing apparatus 100 is provided to the information processing apparatus 100 by a storage medium 37 such as a CD-ROM. That is, when the storage medium 37 storing the program related to the processing is set in the driver 27, the driver 27 reads the program from the storage medium 26, and the read program is transferred to the hard disk 34 via the bus B. Installed. When this process is started, the CPU 11 starts the process according to the program installed in the hard disk 34. Note that the storage medium 27 is not limited to a CD-ROM as a medium for storing the program, and may be any medium that can be read by a computer.

  In addition, a program related to processing performed in the information processing apparatus 100 may be downloaded from the outside by communication means via the Ethernet (registered trademark) I / F 21, USB 22, IEEE1284 23, or the like.

  Next, a functional configuration of the information processing apparatus 100 that has a hardware configuration as shown in FIG. 3, enables a plurality of different image forming processes, and has a plurality of Web applications will be described.

  FIG. 4 is a block diagram showing a functional configuration of the information processing apparatus according to the first embodiment of the present invention. In FIG. 4, the information processing apparatus 100 can be connected to the client PC 40 via the Internet 16 and provides information as a response to the Web page request in response to the Web page request for requesting the Web page from the client PC 40. Computer. For convenience of explanation, the information processing apparatus 100 is configured to be connected to one client PC 40 via the Internet 16, but can be connected to a plurality of client PCs 40. The client PC 40 is a computer terminal having a web browser.

  The information processing apparatus 100 mainly includes an HTTP (Hyper Text Transfer Protocol) daemon 2, a Web application library 110, a Web page library 120, a user switching management module 130, a session library 132, an authentication module 134, a Web A page handler 200, a network library 102, a nonvolatile RAM 14, a SOAP (Simple Object Access Protocol) library 201, an XML (eXtensible Markup Language) library 203, an XSLT (XSL Transformations) processor 205, and a plurality of Web applications A Web page function (WPF) 300.

  The information processing apparatus 100 receives a request from the client PC 40 according to HTTP, and provides information according to the request as a response to the request.

  The HTTP daemon 2 performs communication control according to HTTP. That is, the HTTP daemon 2 receives a Web page request from the client PC 40 according to HTTP, and transmits an HTML (HyperText Markup Language) response corresponding to the Web page request to the client PC 40.

  The web application library 110 absorbs a difference between a data transmission / reception processing sequence performed via the Internet 16 and a data transmission / reception processing sequence with each web application by a predetermined sequence control process. The web application library 110 is a processing unit common to a plurality of web applications.

  The Web page library 120 analyzes a request from the client PC 40 and generates a response to the client PC 40, and is a processing unit common to a plurality of Web applications of the Web page function 300. The Web page library 120 converts the response described in XML by the Web page handler 200 into a display format by HTML by the XSLT processor 205.

  In addition, the Web page library 120 performs authentication processing for a request from the client PC 40 with the user switching management module 130, the session library 132, and the authentication module 134.

  The user switching management module 130 creates a session in the session library 132 and performs user authentication by the authentication module 132 for the initial access by the user. The session library 132 holds the session after creating the session by the initial access until the end of user authentication by the initial access.

  The authentication module 134 performs user authentication based on user information registered in advance using the user name (account) and password received from the client PC 1.

  The web page handler 200 is a processing unit that converts between a processing language that can be interpreted by the web page function 300 and a processing language that is interpreted by communication control based on a request and a response that are made between the client PC 40. The web page handler 200 calls a web application of the web page function 300 corresponding to the web page request via a CGI (Common Gateway Interface). Further, the Web page handler 200 makes a serialization request for Web page display information to the SOAP library 201 in order to describe the Web page display information notified from the Web page function 300 in XML.

  The network library 102 manages HTTP connection information related to the connection with the client PC 40. The network library 102 stores this HTTP connection information in the nonvolatile RAM 14 and refers to it as necessary. In response to a request for path information necessary when providing a Web page from the Web page handler 200, URL path information managed by the HTTP connection information is provided to the Web page handler 200.

  The SOAP library 201 uses the XML library 203 in response to a serialization request for Web page display information from the Web page handler 200 to perform data conversion by describing the Web page display information given as a C language variable in XML. To serialize. In the present embodiment, serializing means describing Web page display information notified from the Web page function 300 by XML. The serialized Web page display information is provided to the Web page handler 200 as a response DOM (Document Object Model).

  The XML library 203 serializes Web page display information in XML by being used by the SOAP library 201. Further, the XML library 203 is used by the XSLT processor 205 to generate HTML indicating Web page display information.

  The XSLT processor 205 creates a response HTML in response to the XSL conversion request of the response DOM from the web page library 120. The response HTML is provided to the web page library 120.

  Each Web application of the Web page function 300 returns Web page display information to the Web page handler 200 when a function call is made from the Web page handler 200.

  The page transition refers to displaying another Web page linked to the Web page from the displayed Web page. In this case, page transitions between a plurality of Web pages that can be provided by the same Web application and page transitions between a plurality of Web pages that can be provided by different Web applications are included.

  Next, a user authentication method according to an embodiment of the present invention will be described with reference to FIGS. FIG. 5 is a diagram showing a processing sequence for realizing the user authentication method by the initial login according to the first embodiment of the present invention. FIG. 6 is a diagram showing a processing sequence for realizing the user authentication method by page transition according to the first embodiment of the present invention. FIG. 7 is a diagram showing a processing sequence for realizing the user authentication method by user switching according to the first embodiment of the present invention. 5, 6 and 7 show a continuous processing sequence. Further, it is assumed that a user who accesses the information processing apparatus 100 has at least two user names (accounts).

  In FIG. 5, when the user performs initial access to the information processing apparatus 100 using the Web browser of the client PC 40 (step S <b> 11), “Login.cgi” requesting login is sent to the information processing apparatus 100. Called (step S12).

  That is, in the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the Web page library 120 via the Web application library 110 calls the user switching management module 130 by “Get Login.cgi”.

  Since the session ID is not set in the request, the user switching management module 130 first makes a session creation request to the session library 132 (step S13). The session library 132 newly creates a session and returns the creation completion to the user switching management module 130 (step S14). The session library 132 starts managing the created session.

  The user switching management module 130 displays the basic authentication screen on the client PC 40 by transmitting the session ID together with the 401 error (step S15).

  In the client PC 40, when the user inputs a user name and password from the displayed basic authentication screen, the “Get Login” in which the input user name, password, and session ID notified from the information processing apparatus 100 are set. .Cgi "is transmitted as a request to the information processing apparatus 100 (step S16).

  For example, a screen 41 as shown in FIG. 8 is displayed on the client PC 40 as a basic authentication screen. On the screen 41 shown in FIG. 8, for example, the user inputs “seiji” as the first user name, inputs the password, and clicks the OK button. The user name “seiji” and the password “seijipassword” input in this way are transmitted to the information processing apparatus 100 together with the session ID.

  In the information processing apparatus 100, the user switching management module 130 is called again by “Get Login.cgi”. The user switching management module 130 notifies the authentication module 134 of the user name and password (step S17). The authentication module 134 executes user authentication processing based on the notified user name and password, and returns an authentication result (authentication success or authentication failure) (step S18).

  When the notification of successful authentication is received, the user switching management module 130 notifies the session library 132 of the session ID and requests to discard the session (step S19). The session library 132 discards the session by deleting the session information specified by the notified session ID, and returns that the session discard has been completed (step S20). The session is discarded when the authentication is successful in this way, or when the valid period of the session has passed (when timed out).

  Then, the user switching management module 130 calls the web page function 300 for displaying the top page (step S21). The web page function 300 notifies the display information of the top page to the web page library 120 (step S22).

  The display information of the top page output from the Web page function 300 is transmitted to the client PC 40 as a top page displayed by HTML via the Web page library 120, the Web application library 110, and the HTTP daemon 2 (step S23). For example, a top page provided with a user switching button for changing to another user is displayed on the Web browser of the client PC 40.

  For example, a screen 44 as shown in FIG. 9 is displayed on the client PC 40 as a top page. A screen 44 as shown in FIG. 9 has a user switching button 44a for changing the user, and the display information of the top page output by the Web page function 300 is displayed in the display area 44b. When the user makes a page transition, the requested page is displayed in the display area 44b.

  Subsequently, in FIG. 6, when the user makes a page transition on the screen 44 displayed on the client PC 40, the client PC 40 designates a Web page and the same user name notified to the information processing apparatus 100 in step S16. A request in which “seiji” and password “seijipassword” are set is transmitted to the information processing apparatus 100 (step S24).

  In the information processing apparatus 100, when the request is received by the HTTP daemon 2, the request in which the user name “seiji” and the password “seijipassword” are set by the Web page library 120 via the Web application library 110 is sent to the authentication module 134. (Step S25). In this case, since “Get Login.cgi” is not specified in the request, the Web page library 120 calls the authentication module 134 without calling the user switching management module 130.

  The authentication module 134 performs user authentication based on the user name “seiji” and the password “seijipassword”, and notifies the Web page library 120 of the authentication result (step S26). When notified that the authentication is successful, the web page library 120 requests the web page function 300 to create a web page specified by the request (step S27). The web page function 300 executes predetermined processing in response to the page creation request to the web page library 120 and returns page information (step S28).

  The page information returned to the web page library 120 is described in HTML, transmitted to the client PC 40 via the web application library 110 and the HTTP daemon 2, and displayed on the web browser of the client PC 40 (step S29). For example, the TCPIP page is displayed in the display area 44b of the screen 44 shown in FIG.

  Further, in FIG. 7, for example, when the user clicks the user switching button 44a on the screen 44, the client PC 40 designates “Get Login.cgi”, “seiji” as the user name, and “seijipassword” as the password. The set request is transmitted to the information processing apparatus 100 (step S30). At this point, the user authentication information with the first user name “seiji” is still set in the request, but the user has initial access to change from the first user name to the second user name. .

  In the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the web page library 120 via the web application library 110 calls the user switching management module 130 using “Get Login.cgi”.

  Since the session ID is not set in the request, the user switching management module 130 first makes a session creation request to the session library 132 (step S31). The session library 132 newly creates a session, and returns the creation completion to the user switching management module 130 (step S32). The session library 132 starts managing the created session.

  The user switching management module 130 displays the basic authentication screen on the client PC 40 by transmitting the session ID together with the 401 error (step S33).

  In the client PC 40, when the user inputs the user name “taka” and the password “takapassword” as the second user name from the displayed basic authentication screen, the input second user name, password, and information “Get Login.cgi” in which the session ID notified from the processing device 100 is set is transmitted to the information processing device 100 as a request (step S34).

  In the information processing apparatus 100, the user switching management module 130 is called again by “Get Login.cgi”. The user switching management module 130 notifies the authentication module 134 of the user name and password (step S35). The authentication module 134 executes user authentication processing based on the notified user name and password, and returns an authentication result (authentication success or authentication failure) (step S36).

  When the notification of successful authentication is received, the user switching management module 130 notifies the session library 132 of the session ID and requests the session to be discarded (step S37). The session library 132 discards the session by deleting the session information specified by the notified session ID, and returns that the session discard has been completed (step S38). The session is discarded when the authentication is successful in this way, or when the valid period of the session has passed (when timed out).

  Then, the user switching management module 130 calls the web page function 300 for displaying the top page (step S39). The web page function 300 notifies the display information of the top page to the web page library 120 (step S40).

  The display information of the top page output from the Web page function 300 is transmitted to the client PC 40 as a top page displayed by HTML via the Web page library 120, the Web application library 110, and the HTTP daemon 2 (step S41).

  Next, Login. The login process executed by calling cgi will be described with reference to FIG. FIG. 10 is a flowchart for explaining the login processing according to the first embodiment of the present invention. In FIG. 10, the cookie ON / OFF of the received request is checked (step S51).

  If Cookie is OFF, a Cookie error message is output (step S52), and "200" indicating that the request has been normally received is returned (step S53). Then, a response in which “200” is set is transmitted to the client (step S68).

  If Cookie is ON, a predetermined function is called to obtain a session object from the authentication module 134 (step S54). And the acquisition result of the session structure as a session object is judged (step S55).

  If the acquisition result is “NULL”, it is determined that the session structure could not be acquired due to some server error such as an area allocation error, a server error is output (step S56), and the server cannot process the request. “503” is returned (step S57). Then, a response in which “503” is set is transmitted to the client PC 40 (step S68).

  If the session structure can be acquired, it is checked whether the session structure is a new session (step S58). If it is a session structure of an existing session, user authentication processing is executed (step S59).

  The authentication result is checked (step S60). If the authentication result indicates authentication failure, “401” indicating that user authentication is required is returned (step S67). Then, a response in which “401” is set is transmitted to the client (step S68).

  If the authentication result indicates successful authentication, a top page is created (step S61), and "200" indicating that the request has been received normally is returned (step S62). Then, “200” is set, and a response indicating the top page information is transmitted to the client PC 40 (step S68).

  On the other hand, if it is determined in step S58 that the session is a new session, a timeout is set (step S63), and a data area for storing session attributes is secured (step S64). It is determined whether or not the area has been secured (step S65). When the area securing fails, the above-described steps S56, S57 and S68 are executed, and the login process is terminated. If the area reservation is successful, the session attribute (item set in the session object as shown in FIG. 11) is set (step S66), and “401” indicating that user authentication is required is returned (step S67). ). Then, a response in which “401” is set is transmitted to the client PC 40 (step S68), and the login process is terminated.

  As described above, according to the present invention, the session library 132 is configured to hold the session until the user authentication is successful or until timeout, so that the session holding period can be shortened as compared with the conventional authentication method.

  In addition, since a session is not required at the time of page transition and user authentication is performed by the user name and password set in the request directly by the authentication module 134, authentication information can be taken over even if the process changes due to page transition. it can.

  Furthermore, since a 401 error can be returned to the client PC 40 in order to perform user authentication even at the time of user switching, the user executes user authentication with a different user name without closing the Web browser of the client PC 40. be able to.

  Accordingly, user authentication can be executed without delay even between a plurality of processes or across a plurality of Web applications.

FIG. 11 is a diagram showing an example of session object information according to the first embodiment of the present invention. 11, the session object 5a, called a session ID for identifying the session, session state, session expiration date indicates when the time-out, the session time remaining before a timeout, the session management information including information about the user, the timeout Information indicating a session end function pointer indicating a pointer to a function for performing the end processing is included.

  A case where a screen for user switching cannot be output will be described with reference to FIG. FIG. 12 is a diagram illustrating a case where the authentication screen is canceled. In FIG. 12, after the processing from step S30 to S33 shown in FIG. 7 is performed and the basic authentication screen is displayed on the client PC 40, the user presses the cancel button on the basic authentication screen as shown in FIG. When is pressed (step S33-2), the client PC 40 outputs an authentication error message, and the authentication processing request is not made to the information processing apparatus 100 as the Web server.

  In such a situation, when the user presses the login button again to make a user switching request (for example, switching the user from seiji to taka) (step S33-4), the client PC 40 again requests the Web authentication system. (Step S33-6). Since the information processing apparatus 100 holds session information, the user name (seiji) and password that have been authenticated before are used, and the authentication process is automatically performed without the user entering the user name and password. And the top page is displayed on the client PC 40 (steps S35 to S41). Originally, the information processing apparatus 100 wants to return an authentication error, but performs an authentication process with previously performed authentication information and succeeds in authentication. Therefore, the authentication error cannot be returned, and the top after the authentication process. The page will be output. If you have logged in once, this can happen.

  A case where an authentication error is output when the user inputs a correct user name and password will be described with reference to FIG. FIG. 13 is a diagram illustrating a case where the user inputs a correct user name and password. In FIG. 13, the user switching management module 130 displays a basic authentication screen on the client PC 40 by transmitting a session ID together with a 401 error (step S33), and then the user enters an incorrect user name and password due to an input error or the like. When the combination is input, authentication fails and the basic authentication screen is displayed again on the client PC 40 (step S90).

  Thus, if the session ID times out in the session library 132 during the authentication failure, the session is abandoned (step S91). Since the client PC 40 cannot recognize that the session has been abandoned, when the correct user name and password combination is input by the user after the session is abandoned (step S92), the user switching management module 130 causes the session library to Since the presence of the session cannot be confirmed at 132, an authentication error is returned (step S93). Therefore, there is a possibility that the user may not be able to display the top page even though the user name and password combination can be finally input.

  In the following, a second embodiment for solving the case where it is not performed as planned depending on the method of use of the user in the first embodiment as described above will be described. In the second embodiment, the hardware configuration and functional configuration of the information processing apparatus 100 are the same as those in the first embodiment, and thus the description thereof is omitted. In the second embodiment, a processing sequence for solving the problem in the first embodiment by storing the number of times of authentication is described. In the following description, the user switching management module 130 is a module called by prelogin.cgi, and the authentication module 134 is a module called by login.cgi that specifies authentication information.

  FIG. 14 is a diagram showing a processing sequence for realizing a normal initial login in the user authentication method for storing the number of authentications according to the second embodiment of the present invention. In FIG. 14, when the user makes an initial access to the information processing apparatus 100 using the Web browser of the client PC 40 (step S101), a login request is made (step S102). In this case, by preliminarily accessing a predetermined site (Web page) from the Web browser, “prelogin.cgi” associated in advance is called to the information processing apparatus 100. “Prelogin.cgi” specifies that the information processing apparatus 100 is to perform authentication processing according to the number of authentications.

  In the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the Web page library 120 via the Web application library 110 calls the user switching management module 130 by “Get prelogin.cgi”.

  The user switching management module 130 receives prelogin. Since cgi is specified and no session ID is set in the request, first, a session creation request is made to the session library 132 (step S103). The session library 132 newly creates session management information (session object), and returns the creation completion to the user switching management module 130 (step S104). The session library 132 starts managing the created session.

  Upon receiving the notification of the completion of session creation, the user switching management module 130 sets an initial value of the number of authentications for the session library 132 (step S105). The session library 132 authenticates in the session management information (session object). The value of the number of times is initialized, and setting completion is returned to the user switching management module 130 (step S106). The user switching management module 130 sends a page written in JavaScript (registered trademark) that automatically calls the authentication processing module (login.cgi) using the Web browser of the client PC 40 to the Web library 110 in response to the request. The Web library 110 notifies the client PC 40 of a page described in JavaScript (registered trademark) that calls the authentication processing module (login.cgi) as a response indicating “Response 200”. Is transmitted (step S108).

  Upon receiving the normal termination, the client PC 40 automatically requests login processing (step S109). In this case, the client PC 40 automatically reads “Login.cgi” from the information processing apparatus 100 as described in the first embodiment (step S110). In this case, in the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the web page library 120 via the web application library 110 calls the user switching management module 130 using “Get Login.cgi”.

  The user switching management module 130 acquires session management information from the session library 132 based on the session ID (steps S111 and S112), and the authentication count of the session management information acquired from the session library 132 is zero (initial value). Therefore, it is determined that authentication has failed (step S113), and the session library 132 is changed to a value obtained by incrementing the number of authentications by 1 (step S114). In this case, the value is changed to “1”. The user switching management module 130 displays the basic authentication screen on the client PC 40 by transmitting the session ID together with the 401 error (step S116).

  In the client PC 40, when the user inputs a user name and password from the displayed basic authentication screen, the “Get Login” in which the input user name, password, and session ID notified from the information processing apparatus 100 are set. .Cgi "is transmitted as a request to the information processing apparatus 100 (step S117).

  Similar to the first embodiment, for example, a screen 41 as shown in FIG. 8 is displayed on the client PC 40 as a basic authentication screen. On the screen 41 shown in FIG. 8, for example, the user inputs “seiji” as the first user name, inputs the password, and clicks the OK button. The user name “seiji” and the password “seijipassword” input in this way are transmitted to the information processing apparatus 100 together with the session ID.

  In the information processing apparatus 100, the user switching management module 130 is called again by “Get Login.cgi”. The user switching management module 130 notifies the authentication module 134 of the user name and password (step S118). The authentication module 134 executes user authentication processing based on the notified user name and password, and returns the authentication result (authentication success or authentication failure) (step S119).

  When the notification of successful authentication is received, the user switching management module 130 notifies the session library 132 of the session ID and requests to discard the session (step S120). The session library 132 discards the session by deleting the session information specified by the notified session ID, and returns that the session discard has been completed (step S121). The session is discarded when the authentication is successful in this way, or when the valid period of the session has passed (when timed out).

  Upon receiving the discard completion from the session library 132, the user switching management module 130 transmits “Response 200” as a response to the client PC 40 (step S122). In this case, the user switching management module 130 returns a page created by JavaScript (registered trademark) that automatically calls a page to be displayed next to the client PC 40.

  When the client PC 40 receives the normal end as a response, the client PC 40 requests a top page (step S123). In this case, a page created with JavaScript (registered trademark) is used to request a top page in which authentication information entered by the user on the basic authentication screen is set.

  At the time of processing in step S123, for example, even if the session has timed out, authentication is performed by a page created by JavaScript (registered trademark) that automatically calls the next page to be displayed by the user switching management module 130. A request for a top page to which information is added can be made.

  Since the authentication process is not performed by the user switching management module 130 using the basic authentication screen, the top page request is made directly to the web page library 120, and the web page library 120 authenticates the authentication module 134 in response to the top page request. When the request is made (step S124) and authentication success is returned from the authentication module 134 (step S125), the Web page function 300 corresponding to the request for the top page (creating the top page) is called (step S126). The web page function 300 notifies the display information of the top page to the web page library 120 (step S127). In this case, if authentication failure is returned, an error is returned to the client PC 40 without calling the Web page function 300.

  The display information of the top page output from the Web page function 300 is transmitted to the client PC 40 as a top page displayed by HTML via the Web page library 120, the Web application library 110, and the HTTP daemon 2 (step S128). For example, a top page provided with a user switching button for changing to another user is displayed on the Web browser of the client PC 40.

  For example, a screen 45 as shown in FIG. 15 is displayed on the client PC 40 as a top page. In the screen 45 as shown in FIG. 15, a login button 45a is provided, and the user can switch the user by clicking the login button 45a. A processing sequence relating to such user switching will be described with reference to FIG.

  FIG. 16 is a diagram showing a processing sequence for realizing user switching in the user authentication method for storing the number of times of authentication according to the second embodiment of the present invention. In FIG. 16, the user clicks on the login button 45a from the screen 45 shown in FIG. 15 displayed on the Web browser of the client PC 40 (step S151). In this case, “prelogin.cgi” set in advance corresponding to the login button 45a is called to the information processing apparatus 100 (step S152). “Prelogin.cgi” specifies that the information processing apparatus 100 is to perform authentication processing according to the number of authentications.

  In the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the Web page library 120 via the Web application library 110 calls the user switching management module 130 by “Get prelogin.cgi”.

  The user switching management module 130 receives prelogin. Since cgi is specified and the session ID is set, first, session management information is acquired from the session library 132 (steps S153 and S154).

  When the session management information is acquired, the user switching management module 130 sets an initial value of the number of authentications for the session library 132 (step S155). The session library 132 sets the number of authentications in the session management information (session object). The value is initialized, and setting completion is returned to the user switching management module 130 (step S156). The user switching management module 130 sends a page written in JavaScript (registered trademark) that automatically calls the authentication processing module (login.cgi) using the Web browser of the client PC 40 to the Web library 110 in response to the request. The Web library 110 notifies the client PC 40 of a page described in JavaScript (registered trademark) that calls the authentication processing module (login.cgi) as a response indicating “Response 200”. Is transmitted (step S158).

  Upon receipt of the normal termination, the client PC 40 automatically requests a login process (step S159). In this case, the client PC 40 automatically reads “Login.cgi” from the information processing apparatus 100 as described in the first embodiment (step S160). In this case, in the information processing apparatus 100, after receiving a request from the client PC 40 by the HTTP daemon 2, the web page library 120 via the web application library 110 calls the user switching management module 130 using “Get Login.cgi”.

  The user switching management module 130 acquires session management information from the session library 132 based on the session ID (steps S161 and S162), and the authentication count of the session management information acquired from the session library 132 is zero (initial value). Therefore, authentication failure is assumed (step S163), and the session library 132 is changed to a value obtained by incrementing the number of authentications by 1 (step S164). In this case, the value is changed to “1”. The user switching management module 130 displays the basic authentication screen on the client PC 40 by transmitting the session ID together with the 401 error (step S166).

  In the client PC 40, when the user inputs a user name and password from the displayed basic authentication screen, the user name (taka) input for user switching, the password, the session ID notified from the information processing apparatus 100, and “Get Login.cgi” is set as a request to the information processing apparatus 100 (step S167).

  Similar to the first embodiment, for example, a screen 41 as shown in FIG. 8 is displayed on the client PC 40 as a basic authentication screen. On the screen 41 shown in FIG. 8, for example, the user inputs “taka” as the second user name, inputs the password, and clicks the OK button. The user name “taka” and the password “takapassword” input in this way are transmitted to the information processing apparatus 100 together with the session ID.

  In the information processing apparatus 100, the user switching management module 130 is called again by “Get Login.cgi”. The user switching management module 130 notifies the authentication module 134 of the user name and password (step S168). The authentication module 134 executes user authentication processing based on the notified user name and password, and returns the authentication result (authentication success or authentication failure) (step S169).

  When the notification of successful authentication is received, the user switching management module 130 notifies the session library 132 of the session ID and requests to discard the session (step S170). The session library 132 discards the session by deleting the session information specified by the notified session ID, and returns that the session discard has been completed (step S171). The session is discarded when the authentication is successful in this way, or when the valid period of the session has passed (when timed out).

  Upon receiving the discard completion from the session library 132, the user switching management module 130 transmits “Response 200” as a response to the client PC 40 (step S172). In this case, the user switching management module 130 returns a page created by JavaScript (registered trademark) that automatically calls a page to be displayed next to the client PC 40.

  When the client PC 40 receives the normal end in the response, the client PC 40 requests the top page (step S173). In this case, a page created with JavaScript (registered trademark) is used to request a top page in which authentication information entered by the user on the basic authentication screen is set.

  At the time of the processing in step S123, for example, even if the session has timed out, the user switching management module 130 automatically calls the next page to be displayed, and the page created by JavaScript (registered trademark) It is possible to request a top page to which authentication information for switching (second user) is added.

  Since the authentication process is not performed by the user switching management module 130 using the basic authentication screen, the top page request is made directly to the web page library 120, and the web page library 120 authenticates the authentication module 134 in response to the top page request. When the request is made (step S174) and authentication success is returned from the authentication module 134 (step S175), the Web page function 300 corresponding to the request for the top page (creating the top page) is called (step S176). The web page function 300 notifies the display information of the top page to the web page library 120 (step S177). In this case, if authentication failure is returned, an error is returned to the client PC 40 without calling the Web page function 300.

  The display information of the top page output from the Web page function 300 is transmitted to the client PC 40 as a top page displayed by HTML via the Web page library 120, the Web application library 110, and the HTTP daemon 2 (step S178). For example, a top page provided with a user switching button for changing to another user is displayed on the Web browser of the client PC 40.

  A processing flow of the user switching management module 130 for realizing the above-described processing sequence will be described with reference to FIG. FIG. 17 is a flowchart for explaining a process related to the user switching management module according to the second embodiment of the present invention. In FIG. 17, login.cgi, which calls a process related to the user switching management module 130, checks the cookie ON / OFF of the received request (step S251).

  When Cookie is OFF, a Cookie error message is output (step S252), and “200” indicating that the request has been normally received is returned (step S253). Then, a response in which “200” is set is transmitted to the client PC 40 (step S268).

  If Cookie is ON, a predetermined function is called to obtain a session object (step S254). And the acquisition result of the session structure as a session object is judged (step S255).

  If the acquisition result is “NULL” in step S255, that is, if it is determined that the authentication has failed a plurality of times, or that prelogin.cgi has been called again after the user selects cancel, a server error is output (step In S256), “503” indicating that the server cannot process the request is returned (step S257). Then, a response in which “503” is set is transmitted to the client PC 40 (step S268).

  If the session structure can be acquired in step S255, it is checked whether or not the session is a new session (step S258). If it is a session structure of an existing session, the number of authentications is set to zero (step S259). Then, “200” (normal end) is set as a response (step S260), and a response indicating “200” (normal end) is sent to the client PC 40 together with a page that automatically calls login.cgi by JavaScript (registered trademark). Transmit (step S268).

  On the other hand, if it is determined in step S258 that the session is a new session, a timeout is set (step S263), and a data area for storing session attributes is secured (step S264). It is determined whether the area has been secured (step S265). If the area reservation fails, the above-described steps S256, S257, and S68 are executed, and the login process is terminated. If the area reservation is successful, the session attributes (including the number of authentications, items set in the session object 5b as shown in FIG. 19) are set (step S266), and “200” indicating normal termination is returned (step S266). S267). In this case, an initial value (zero) is set as the number of authentications. Then, a response in which “200” is set together with a page for automatically calling login.cgi by JavaScript (registered trademark) is transmitted to the client PC 40 (step S268), and the login process is terminated.

  In the processing in step S268, the response is transmitted to the client PC 40 together with the page that automatically calls login.cgi by JavaScript (registered trademark) in the case of processing subsequent to steps S260 and S267. In the case of following steps S257 and S253, the page calling login.cgi is not transmitted.

  FIG. 18 is a flowchart for explaining the processing related to the authentication module according to the second embodiment of the present invention. In FIG. 18, prelogin.cgi that calls processing related to the authentication module 134 checks the cookie ON / OFF of the received request (step S351).

  When Cookie is OFF, a Cookie error message is output (step S352), and “200” indicating that the request has been normally received is returned (step S353). Then, a response in which “200” is set is transmitted to the client PC 40 (step S368).

  If Cookie is ON, a predetermined function is called to obtain a session object (step S354). And the acquisition result of the session structure as a session object is judged (step S355).

  If the acquisition result is “NULL” in step S355, that is, if it is determined that the authentication has failed a plurality of times or that prelogin.cgi has been called again after the user selects cancel, a server error is output (step S356), “503” indicating that the server cannot process the request is returned (step S357). Then, a response in which “503” is set is transmitted to the client PC 40 (step S368).

  If the session structure can be acquired in step S355, it is checked whether or not the session is a new session (step S358). If it is a session structure of a new session, the session is discarded (step S359), and a message indicating that access for authentication is requested (for example, a message such as “Press the login button”) is output ( In step S360), “408” requesting access (re-login) from the beginning is returned again (step S361), and the process is terminated. A case where it is determined that the session is a new session in this process is a case where authentication information is input after the session is discarded due to a timeout or the like.

  On the other hand, if it is determined in step S358 that the session is an existing session, the registration data in which the session attribute (session object item) is registered is acquired (step S362), and the NULL indicates whether the registration data has been acquired. Judgment is made based on whether or not it is a return value (step S363). If it is NULL, the above-described steps S356 and S357 are executed, and this process is terminated.

  On the other hand, if it is determined in step S363 that it is not NULL, it is determined whether or not the number of authentications exceeds a predetermined maximum number of authentications (step S364). If the maximum number of authentications has been exceeded, the session is discarded (step S359). Then, a message indicating that access for authentication is requested (for example, a message such as “Please press the login button”) is output (step S360), “408” is returned (step S361), and the process is performed. finish.

  On the other hand, if the number of authentications is less than or equal to the maximum number of authentications in step S364, user authentication processing is executed (step S365). Then, the authentication result is checked (step S366). If the authentication result indicates an authentication failure, the number of authentications is incremented, and “401” indicating that user authentication is required is returned (step S367), and this process ends.

  If the authentication result indicates successful authentication, the session is discarded (step S368), a top page corresponding to account switching (user switching) is output (step S369), "200" is returned (step S370), and processing is performed. Exit. A page created by JavaScript (registered trademark) that automatically calls a page to be displayed next is returned to the client PC 40.

  On the other hand, if the number of times of authentication is zero in step S364, the number of times of authentication is incremented and “401” is returned (step S371), and this process ends.

  As described above, even when the session is abandoned when the session time-out occurs or when the authentication is successful, it is possible to cope with an unexpected user usage.

  In the first embodiment, the problem that the basic authentication screen is not output and authentication processing is performed with the previous user name and password can be dealt with by confirming the number of authentications.

  That is, in the second embodiment, a request from a user always passes through the user switching management module 130. When prelogin.cgi is called, if there is no session management information, session management information is created and the number of authentications is initialized to the 0th time (for example, steps S103 to S106 in FIG. 14). If there is session management information, the number of authentications is reset to the 0th time (for example, steps S153 to S156 in FIG. 16). When login.cgi is called (for example, step S110 in FIG. 14 and step S160 in FIG. 16), if there is session management information, the basic authentication is performed by increasing the number of authentications and returning an authentication error (401 response). The screen can be displayed (for example, step S116 in FIG. 14 and step S166 in FIG. 16).

  If login.cgi is called after the session has timed out, authentication information can be recognized in the authentication processing module 134, so that an error message prompting re-login can be output (step S360 in FIG. 18). Therefore, even if a correct account name and password are input, an authentication error (401 response) is not returned.

  As described above, according to the present invention, a user change request can be recognized when a Web application provided as a single Web application performs basic authentication by collecting Web applications that operate in separate processes. Can be done easily.

  Even if the page transition exceeds the process, it is not necessary to perform user authentication every time, and the page transition can be facilitated.

  Since session information related to authentication is ensured only at the time of change, unlike the conventional case where the session is managed all the time after authentication, the lifetime is short and the area to be secured can be reduced.

  Even when the user performs an unexpected process, the authentication process can be performed correctly, so that the strength of security can be increased and the convenience of the user can be increased.

  Since the number of authentications is managed on the information processing apparatus 100 side, the number of authentications can be limited without being restricted by the limit on the number of basic authentications performed on the browser side of the client PC 40. It does not depend on the specifications of each Web browser.

It is a figure which shows the example of the conventional authentication method. It is a figure which shows the other example of the conventional authentication method. It is a block diagram which shows the hardware constitutions of the information processing apparatus which concerns on 1st Example of this invention. It is a block diagram which shows the function structure of the information processing apparatus which concerns on 1st Example of this invention. It is a figure which shows the process sequence for implement | achieving the user authentication method by the initial login which concerns on 1st Example of this invention. It is a figure which shows the process sequence for implement | achieving the user authentication method by the page transition based on 1st Example of this invention. It is a figure which shows the process sequence for implement | achieving the user authentication method by the user switching which concerns on 1st Example of this invention. It is a figure which shows the example of the basic authentication screen which concerns on 1st Example of this invention. It is a figure which shows the example of the screen displayed on client PC concerning the 1st Example of this invention. It is a flowchart figure for demonstrating the login process which concerns on 1st Example of this invention. It is a figure which shows the example of information of the session object which concerns on 1st Example of this invention. It is a figure which shows the case where an authentication screen is canceled. It is a figure which shows the case where a user inputs the correct user name and password. It is a figure which shows the process sequence for implement | achieving normal initial login in the user authentication method which memorize | stores the frequency | count of authentication which concerns on 2nd Example of this invention. It is a figure which shows the example of the screen displayed on client PC concerning 2nd Example of this invention. It is a figure which shows the process sequence for implement | achieving user switching in the user authentication method which memorize | stores the frequency | count of authentication which concerns on 2nd Example of this invention. It is a flowchart figure for demonstrating the process regarding the user switching management module which concerns on 2nd Example of this invention. It is a flowchart figure for demonstrating the process regarding the authentication module which concerns on 2nd Example of this invention. It is a figure which shows the example of information of the session object which concerns on 2nd Example of this invention.

Explanation of symbols

2 HTTP daemon 11 CPU
12 ROM
13 RAM
14 Nonvolatile RAM
15 Real-time clock 16 Network 21 Ethernet (registered trademark) I / F
22 USB I / F
23 IEEE1284
24 Hard disk I / F
25 Engine I / F
26 RS-232C I / F
34 Hard Disk 35-1 Plotter 35-2 Scanner 36 Operation Panel 40 Client PC
DESCRIPTION OF SYMBOLS 100 Information processing apparatus 102 Network library 110 Web application library 120 Web page library 130 User switching management module 132 Session library 134 Authentication module 200 Web page handler 201 SOAP library 203 XML library 205 XSLT processor 300 Web page function (WPF)

Claims (5)

A basic authentication screen for allowing the user to input authentication information is displayed on the browser of the client PC connected via the network, and the user is authenticated using the header information of the request in which the authentication information input by the user is set In the web authentication server,
Receiving means for receiving the request transmitted from the browser;
If the request requires authentication, generating means for generating a session object for managing a session with the browser;
Display means for displaying the basic authentication screen on the browser;
Authentication means for authenticating the user based on the authentication information input from the basic authentication screen;
A web authentication server, comprising: a discarding unit that discards the session object when authentication is successful. If authentication is successful by the authentication means, page information generation means for generating page information to be displayed on the page specified in the request;
Further Web authentication server according to claim 1, wherein the further comprising a converting means for converting the page information generated by the page information generation unit into a displayable format in the browser. It said discarding means, according to claim 1 or 2 web authentication server according to, characterized in that destroys the session object has timed out. If you page transition by said request, to suppress the execution of the generating means and said display means, according to claim 1 to 3 web authentication server according to any one claim of and executes the authentication unit directly. A basic authentication screen for allowing the user to input authentication information is displayed on the browser of the client PC connected via the network, and the user is authenticated using the header information of the request in which the authentication information input by the user is set In the web authentication server,
Receiving means for receiving the request transmitted from the browser;
Generating means for generating a session object for managing a session with the browser if the request requires authentication and the authentication is the first request;
Display means for displaying the basic authentication screen on the browser;
Authentication means for authenticating the user based on the authentication information input from the basic authentication screen;
A web authentication server, comprising: authentication success processing means for discarding the session object and transmitting a page request script for requesting the browser to request a page when authentication is successful.

Images