Abstract:
A Web service providing method of a Web service provider providing a Web service comprises a decoding request transmission step transmitting, in response to a request from a client, a decoding request of Web service use permission information related to permission of use of the Web service, to an authentication service provider that provides a service related to authentication, and a decode response reception step, receiving a decode response of the Web service use permission information issued in response to said decoding request of the Web service use permission information, from the authentication service provider.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     The present invention relates to Web service provider and authentication service provider.  
         [0002]     Kerberos is an authentication system for open network (Reference should be made to Non-patent Reference 1).  
         [0003]     Below, the concept of authentication by a third party organization in Kerberos will be explained with reference to  FIG. 1  showing the concept of authentication by a third party organization.  
         [0004]     Referring to  FIG. 1 , the fundamental framework of “authentication by a reliable third party organization” adopted with Kerberos includes the steps of: submitting a request to a KDC (Key Distribution Center), when a client wishes to use a service, for a ticket that permits the use of the service (step ( 1 ) of  FIG. 1 ); get the ticket (step ( 2 ) of  FIG. 1 ); and get the service by submitting the ticket received from the KDC for the service to the server (step ( 3 ) of  FIG. 1 ).  
         [0005]     However, such a model requires caching of the secret key in the side of the client, and there has been a problem of security in that the secret key may leak.  
         [0006]     In order to attend to this problem, the concept of TGT (Ticket Granting Ticket) is proposed.  
         [0007]     Hereinafter, the fundamental concept of safe authentication by a third party organization will be explained with reference to  FIG. 2 , wherein  FIG. 2  is a diagram explaining the concept of safe authentication by a third party organization.  
         [0008]     Referring to  FIG. 2 , the client requests for a TGT to an authentication server (Authentication Server) (step ( 1 ) of  FIG. 2 ), and acquires the TGT from the authentication server (step ( 2 ) of  FIG. 2 ). Next, the client submits the TGT to a TGS (Ticket Granting Server) (step ( 3 ) of  FIG. 2 ), and acquires a ticket (server use permission ticket) permitting the use of a desired service (step ( 4 ) of  FIG. 2 ). Finally, the client submits this ticket (server use permission ticket) for the intended service. Thereby, the use of the service becomes possible.  
         [0009]     In this Kerberos system, the KDC plays the role of AS and also the role of TGS.  
         [0010]     By adopting the method of authentication of  FIG. 2 , the Kerberos system can solve the aforementioned problems and can provide more secure authentication. (Non-patent Reference 1)  
         [0011]     Gijutsu Hyoronsha, Editorial Section II, “Firewall &amp; Network security, Practical Technique-all PCs, The strongest security guide for UNIX users and site managers, “Software Design Security Issue”, Gijutsu Hyoron Publishing, 3.7 Kerberos, An Authentication System for Open Network, November 2000.  
         [0012]     However, in the above conventional authentication method, there has been a need, when it is desired to add a new Web service that requires a use permission, to setup information (such as proof information, and the like) related to the above-mentioned Web service, in the KDC that provides the service of authentication.  
         [0013]     In the case of providing plural Web services, therefore, the need of such additional setup noted above raises the problem of poor efficiency.  
       SUMMARY OF THE INVENTION  
       [0014]     The present invention is made in view of the problems noted above and has its object of providing simple and efficient authentication service and/or Web service.  
         [0015]     In order to solve the foregoing problems, the present invention provides a Web service providing method, comprising: 
        a decode request transmitting step transmitting, in response to a request from a client, a decode request to an authentication service provider providing a service of authentication, said decode request requesting decoding of Web service use permission information related to permission of the use of the Web service; and     a decoded response receiving step receiving a decoded response of the Web service use permission information issued in response to the decode request from the authentication service provider.        
 
         [0018]     As a result of the use of the Web service providing method thus comprising: a decode request transmitting step transmitting, in response to a request from a client, a decode request to an authentication service provider providing a service of authentication, said decode request requesting for decoding of Web service use permission information related to permission of use of a desired Web service; and a decoded response receiving step receiving a decoded response of said Web service use permission information issued in response to said decode request from said authentication service provider, it becomes possible to provide the authentication service and/or the Web service simply and efficiently.  
         [0019]     Here, it should be noted that the “Web service use permission information” used herein corresponds to a Web service use ticket ID, or a Web service use ticket itself, or a part of the Web service use ticket, as will be described later. Also, the “session” used herein corresponds a session ID or the session itself, or a part of the session, as will be described later.  
         [0020]     Further, the present invention provides a Web service proving program, a recording medium storing the Web service providing program and a Web service providing apparatus for solving the foregoing problems.  
         [0021]     Further, the present invention provides an authentication service providing method for providing a service regarding authentication, comprising: 
        a Web service use permission information creating step creating, in response to a request from a client, Web service use permission information related to a use permission of a Web service; and     a decoding step decoding, in response to a request from a Web service provider providing said Web service, corresponding Web service use permission information.        
 
         [0024]     As a result of the use of the authentication service providing method for providing a service regarding authentication thus comprising: a Web service use permit information creating step creating, in response to a request from a client, Web service use permission information related to a use permission of a desired Web service; and a decoding step decoding, in response to a request from a Web service provider providing said Web service, corresponding Web service use permission information, it becomes possible to provide authentication service and/or Web service simply and efficiently.  
         [0025]     Here again, it should be noted that the “Web service use permission information” corresponds to a Web service use ticket ID, or the Web service use ticket itself, or a part of the Web service use ticket, as will be described later. Also, the “user authentication information” used herein corresponds the authentication ticket ID or the authentication ticket itself, or a part of the authentication ticket, as will be described later.  
         [0026]     Further, the present invention provides an authentication service proving program, a recording medium storing the authentication service providing program and a Web service providing apparatus for solving the foregoing problems. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0027]      FIG. 1  is a diagram explaining the concept of authentication by a third party organization;  
         [0028]      FIG. 2  is a diagram for explaining the concept of safe authentication by a third party organization;  
         [0029]      FIG. 3  is a diagram showing the hardware construction of an authentication service providing server;  
         [0030]      FIG. 4  is a diagram showing the hardware construction of a Web service providing server;  
         [0031]      FIG. 5  is a first sequence diagram for explaining an authentication service providing method and/or Web service providing method;  
         [0032]      FIG. 6  is a function diagram showing an example of authentication service;  
         [0033]      FIG. 7  is a functional diagram showing an example of a directory service;  
         [0034]      FIG. 8  is a diagram for explaining an example of an authentication ticket acquisition request;  
         [0035]      FIG. 9  is a diagram for explaining an example of an authentication ticket acquisition response;  
         [0036]      FIG. 10  is a diagram showing an example of an internal structure of an authentication ticket;  
         [0037]      FIG. 11  is a diagram explaining an example of a user information structure;  
         [0038]      FIG. 12  is a diagram explaining an example of a group information structure;  
         [0039]      FIG. 13  is a flowchart explaining an example of an authentication ticket creation processing;  
         [0040]      FIG. 14  is a diagram explaining an example of a Web service use ticket acquisition request;  
         [0041]      FIG. 15  is a diagram explaining an example of a Web service use ticket acquisition response;  
         [0042]      FIG. 16  is a diagram for explaining an example of an internal structure of a Web service use ticket;  
         [0043]      FIG. 17  is a concept diagram of the data inside a ticket administration part;  
         [0044]      FIG. 18  is a flowchart explaining an example of a Web service use ticket creation processing;  
         [0045]      FIG. 19  is a diagram explaining an example of a session start request;  
         [0046]      FIG. 20  is a diagram explaining another example of the session start request;  
         [0047]      FIG. 21  is a diagram explaining an example of Web service use ticket decoding request;  
         [0048]      FIG. 22  is a diagram explaining an example of a Web service use ticket decoding response;  
         [0049]      FIG. 23  is a diagram explaining an example of a session start response;  
         [0050]      FIG. 24  is a diagram explaining an example of an internal structure of the session;  
         [0051]      FIG. 25  is a flowchart explaining an example of a session creation processing;  
         [0052]      FIG. 26  is a flowchart explaining an example of a Web service use ticket decoding processing;  
         [0053]      FIG. 27  is a diagram explaining an example of a directory service use request;  
         [0054]      FIG. 28  is a diagram explaining an example of a directory service use response;  
         [0055]      FIG. 29  is a flowchart showing an example of a user list acquisition processing;  
         [0056]      FIG. 30  is a second sequence diagram explaining authentication service providing method and/or Web service providing method;  
         [0057]      FIG. 31  is a sequence diagram explaining an authentication service providing method and/or Web service providing method for the case in which there exist plural Web services;  
         [0058]      FIG. 32  is a sequence diagram explaining an example of an authentication service providing method and/or Web service providing method for the case another Web service uses the Web service use ticket;  
         [0059]      FIG. 33  is a block diagram showing the construction of a integrated machine; and  
         [0060]      FIG. 34  is a block diagram showing the hardware construction of the integrated machine. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0061]     Hereinafter, embodiments of the present invention will be explained with reference to the drawings.  
       EMBODIMENT 1  
       [0062]      FIG. 3  shows the hardware construction of an authentication service providing server  1 .  
         [0063]     Referring to  FIG. 3 , the hardware construction of the authentication service providing server  1  includes an input device  11 , a display device  12 , an drive apparatus  13 , a ROM (Read Only Memory)  15 , a RAM (Random Access Memory)  16 , a CPU (Central Processing Unit)  17 , an interface apparatus  18 , and an HDD (Hard Disk Drive)  19 , wherein the devices  11 - 19  are connected to a bus B.  
         [0064]     The input device  11  is formed of keyboard, mouse, and the like, operated by the user of the authentication service providing server  1  and is used to input various operational signals to the authentication service providing server  1 .  
         [0065]     The display device  12  is formed a display, and the like, used by the user of the authentication service providing server  1  and is used to display various information.  
         [0066]     The interface apparatus  18  is the interface that connects the authentication service providing server  1  to a network, and the like.  
         [0067]     Application programs corresponding to the authentication service  30  to be described later and a main program that controls the overall processing of the authentication service providing server  1  are provided to the authentication service provider server  1  by a recording medium  14  such as a CD-ROM, and the like, or downloaded through a network. Thereby, the recording medium  14  is set to the drive apparatus  13 , and the foregoing application programs or the main programs, and the like, are installed to the HDD  19  from the recording medium  14  via the drive apparatus  13 .  
         [0068]     It should be noted that the ROM  15  stores data, and the like, while the RAM  16  reads out the foregoing application programs or the main program, and the like, from the HDD  19  at the time of activation of the authentication service providing server  1  and holds the same therein. Thereby, the CPU  17  reads the RAM  16  and carries out processing in accordance with the above-mentioned application programs or main program, and the like thus held in the RAM  16 .  
         [0069]     Further, the HDD  19  stores therein an authentication ticket  50 , a Web service use ticket  60 , user information, group information, and the like, to be described later, in addition to the programs.  
         [0070]     Hereinafter, the hardware construction of a Web service providing server  2  will be explained with reference to  FIG. 4 .  
         [0071]      FIG. 4  is the hardware construction diagram of the Web service providing server  2 .  
         [0072]     Referring to  FIG. 4 , the Hardware construction of the Web service providing server  2  includes an input device  21 , a display device  22 , a drive apparatus  23 , a ROM (Read Only Memory)  25 , a RAM (Random Access Memory)  26 , a CPU (Central Processing Unit)  27 , an interface apparatus  28 , and an HDD (Hard Disk Drive)  29 , wherein the devices  21 - 29  are connected to a common bus B.  
         [0073]     Here, it should be noted that the input device  21  is formed of a keyboard, a mouse, and the like, operated by the user of the Web service providing server  2  and is used to input various operational signals to the Web service providing server  2 .  
         [0074]     The display device  22  is formed of a display, and the like, used by the user of the Web service providing server  2  and displays various information.  
         [0075]     The interface apparatus  28  is an interface connecting the Web service providing server  2  to the network, and the like.  
         [0076]     Here, it should be noted that application programs corresponding to a directory service  40  to be described later or a main program, and the like, used for controlling the overall processing of the Web service providing server  2 , are provided to the Web service providing server  2  by a recording medium  24  such as a CD-ROM, or downloaded via the network. Thereby, the recording medium  24  is set to the drive apparatus  23 , and the application programs or main program, and the like, are installed to the HDD  29  from the recording medium  24  through the drive apparatus  23 .  
         [0077]     It should be noted that the ROM  25  stores data, and the like, while the RAM  26  reads out the application programs or the main program, and the like, from the HDD  29  at the time of activation of the Web service providing server  2  and holds the same therein. Further, the CPU  27  reads the RAM  26  and executes the processing in accordance with the application programs, the main program, and the like, thus held in the RAM  26 .  
         [0078]     Further, the HDD  29  is used to store, in addition to the programs, the URL of the authentication service  30  that provides the services related to authentication, or the character sets such as “repository Service”, and the like, used for distinguishing the directory service  40 . The URL of the authentication service  30  becomes necessary when using a session  70  and/or a directory service  40  as will be described later, while the character set becomes necessary when using the directory service  40 .  
         [0079]     As described previously, the present embodiment will be described based on the assumption that: the authentication service  30  to be described later is implemented in the authentication service providing server  1  in the embodiment of the present invention; and that the directory service  40  to be described later is implemented in the Web service providing server  2 . On the other hand, the authentication service  30  and the directory service  40  may be implemented in the same server, and the like.  
         [0080]     Hereinafter, examples of authentication service providing method and/or Web service providing method of the present invention will be described with reference to  FIG. 5 .  
         [0081]      FIG. 5  is a first sequence diagram explaining the authentication service providing method and/or Web service providing method of the present invention.  
         [0082]     Referring to  FIG. 5 , a client  3  that wishes to use a Web service provided by the Web service providing server  2  creates an acquisition request for an authentication ticket  50 , which is a ticket that authenticates the user of the client  3 , and transmits the same to an authentication service  30  (Sequence SQ 1  of  FIG. 5 ).  
         [0083]     Details of the authentication ticket acquisition request will be described later by using  FIG. 8 .  
         [0084]     The authentication service  30  carries out authentication on the basis of the user name, password, and the like, included in the authentication ticket acquisition request from the client  3  and creates an authentication ticket  50 . Further, the authentication server  30  creates an authentication ticket acquisition response including an ID (authentication ticket ID) of the authentication ticket  50  and transmits the same to the client  3  (Sequence SQ 2  of  FIG. 5 ).  
         [0085]     Details of the authentication ticket acquisition response will be described later by using  FIG. 9 .  
         [0086]     Upon reception of the authentication ticket acquisition response, the client  3  transmits an acquisition request for a Web service use ticket  60 , which includes the authentication ticket ID and permits the use of the Web service (for example, the use of the directory service  40 ) provided by the Web service providing server  2 , to the authentication service  30  (sequence SQ 3  of  FIG. 5 ).  
         [0087]     Details of the Web service use ticket acquisition request will be described later with reference to  FIG. 14 . For example, the client  3  adds distinction information and the like requested by the Web service to be used (such as the directory service  40 ) for distinguishing that Web service in the Web service use ticket acquisition request, and transmits the same to the authentication service  30 .  
         [0088]     The authentication service  30  determines, on the basis of the authentication ticket ID included in the Web service use ticket acquisition request, whether or not there exists a valid authentication ticket  50  corresponding to the authentication ticket ID, and if it is judged that there exists such a valid authentication ticket  50  in correspondence to the authentication ticket ID, the authentication service  30  creates the Web service use ticket  60  corresponding to the Web service use ticket acquisition request. Further, the authentication service  30  creates a Web service use ticket acquisition response containing the ID (Web service use ticket ID) of the Web service use ticket  60  and transmits the same to the client  3  (sequence SQ 4  of  FIG. 5 ).  
         [0089]     For example, in the case the distinction information that distinguishes the Web services is included in the Web service use ticket acquisition request, the authentication service  30  creates the Web service use ticket  60  including the distinction information that distinguishes that Web service and creates a Web service use ticket acquisition response that contains the ID (Web service use ticket ID) of the Web service use ticket  60 . Further, the authentication service  30  transmits the same to the client  3 .  
         [0090]     Details of the Web service use ticket acquisition response will be described later by using  FIG. 15 . Here, it should be noted that the client  3  can transmit the Web service use ticket acquisition request containing the authentication ticket ID to the authentication service  30  during the interval in which the authentication ticket  50  is valid, by using the authentication ticket ID contained in the authentication ticket acquisition response received in the sequence SQ 2 . The authentication service  30  judges, based on the authentication ticket ID contained in the Web service ticket acquisition request, whether or not there exists a corresponding valid authentication ticket  50 , and if it is judged that there exists such a valid thicket  50 , the authentication service  30  creates a Web service use ticket  60  corresponding to the Web service use ticket acquisition request. Further, the authentication service  30  creases a Web service use ticket acquisition response containing the Web service use ticket ID and transmits the same to the client.  
         [0091]     Thus, once the authentication is achieved, the client can acquire the Web service use ticket  60  (or Web service use ticket ID) corresponding to the Web service to be used, without carrying out the authentication process each time, by repeatedly using the authentication ticket  50  for the interval in which the authentication is valid.  
         [0092]     When the Web service use ticket acquisition response is received, the client  3  transmits a start request of the session with the directory service  40  containing the Web service use ticket ID and transmits the same to the directory service  40  (sequence SQ 5  of  FIG. 5 ).  
         [0093]     Details of the session start request will be described later by using  FIG. 19  and/or  FIG. 20 .  
         [0094]     The directory service  40  creates the decoding request of the Web service use ticket  60  that contains the distinction information for identifying that Web service use ticket ID and that directory service  40  on the basis of the Web service use ticket ID contained in the session start request, and transmits the same to the authentication service  30  (sequence SQ 6  of  FIG. 5 ).  
         [0095]     Details of the Web service use ticket decoding request will be described later by using  FIG. 21 .  
         [0096]     The authentication service  30  determines whether or not it is a valid Web service use ticket  60  on the basis of the distinction information that distinguishes the Web service use ticket ID and/or directory service  40  contained in the Web service use ticket decoding request, and creates a Web service use ticket decoding response containing the result of the judgment (result of decoding) or the content of the authentication ticket  50  and/or the Web service use ticket  60 . Further, the authentication service  30  transmits the same to the directory service  40  (sequence SQ 7  of  FIG. 5 ).  
         [0097]     Details of the Web service use ticket decoding response will be described later by using  FIG. 22 .  
         [0098]     The directory service  40  creates a session  70  on the basis of the result of the above-mentioned determination contained in the Web service use ticket decoding response and transmits the session start response including the ID of the session  70  to the client  3  (sequence SQ 8  of  FIG. 5 ).  
         [0099]     Details of the session start response will be described later by using  FIG. 23 .  
         [0100]     Upon reception of the session start response, the client  3  creates the use request of the directory service  40  including the session ID and transmits the same to the directory service  40  (sequence SQ 9  of  FIG. 5 ).  
         [0101]     Details of the directory service use request will be described later by using  FIG. 27 .  
         [0102]     The directory service  40  determines, on the basis of the session ID included in the directory service use request, whether or not it is a valid ID, and, when it is determined that it is a valid session ID, carries out the processing according to the directory service use request. Further, the directory service  40  creates a directory service use response corresponding to that directory service use request and transmits the same to the client  3  (sequence SQ 10  of  FIG. 5 ).  
         [0103]     Details of the directory service use response will be described later by using  FIG. 28 .  
         [0104]     As shown in the sequence SQ 6  of  FIG. 5 , the Web service (for example, directory service  40 ), inquires to the authentication service  30 , in the authentication service providing method and/or Web service providing method of the present invention, whether or not the Web service use ticket ID included in the request from the client  3  is a valid Web service use ticket ID.  
         [0105]     Also, as shown in the sequence SQ 7  of  FIG. 5 , the authentication service  30  that has received the inquiry determines whether or not the Web service use ticket ID is a valid Web service use ticket ID, and returns the result to the requesting Web service (for example, directory service  40 ).  
         [0106]     By using such authentication method, the authentication service  30  can provide the authentication service and/or Web service also in the case a new Web service is added to the Web service providing server  2 , by managing the authentication ticket  50  and/or the Web service use ticket  60 , without providing new setting, and the like, in the authentication service  30 .  
         [0107]     Hereinafter, the function and construction of an exemplary authentication service  30  will be explained by using  FIG. 6  showing the functional diagram of the exemplary authentication service.  
         [0108]     As shown in  FIG. 6 , the authentication service  30  includes an authentication distribution part  31 , a ticket administration part  32 , an authentication provider A 33 , an authentication provider B 34 , and a SOAP (Simple Object Access Protocol) stub  35 .  
         [0109]     Here, it should be noted that the SOAP stub  35  is a module for realizing communication by SOAP between the client  3  and/or Web service providing server  2 .  
         [0110]     Further, the authentication distribution part  31  is the module that provides a common interface for various kinds of authentication providers to the client  3  and/or the Web service providing server  2 . For example, the authentication distribution part  31  calls the authentication provider that carries out the authentication according to the provider name.  
         [0111]     The authentication provider A 33 , the authentication provider B 34 , and the like, are the module called “authentication provider”. Here, it should be noted that the authentication provider functions as an adapter or mediator for incorporating various authentication engines into the authentication service  30 . Here, it should be noted that an authentication engine means the system that carries out the actual authentication processing such as password comparison.  
         [0112]     Thus, individual authentication engine has its own interface (protocol). On the other hand, in order to provide the authentication function of each of the authentication engines to the client  3  as the Web service, it is necessary to comply with the interface prescribed with regard to the authentication distribution part  31 . The authentication provider absorbs the original protocols of the individual authentication engines and provides a common interface to the authentication distribution part  31 . Thus, in order to incorporate a new authentication engine into the authentication service  30 , a new authentication provider is implemented. However, the authentication provider itself may have the function of authentication engine.  
         [0113]     The ticket managing part  32  is the module that manages the tickets related to authentication. For example, the ticket managing part  32  manages an authentication ticket  50 , user information, group information, a Web service use ticket  60 , and the like.  
         [0114]     Although the functional construction of the authentication service  30  has been explained in  FIG. 6  for the example having plural authentication providers, it is not necessarily that there exist plural authentication providers, and the authentication service  30  may have only the authentication provider A 33 . In the case of such a construction, the authentication distribution part  31  is not necessarily be included in the construction of the authentication service  30 .  
         [0115]     For the sake of simplicity of explanation, following explanation is made for the case in which the authentication service  30  has plural authentication providers as shown in  FIG. 6  and that the authentication distribution part  31  is also included in the authentication service  30 . This, however, does not limit the implementation of the present invention.  
         [0116]     Hereinafter, the functional construction of an exemplary directory service  40  will be explained by using  FIG. 7 .  
         [0117]      FIG. 7  is a diagram showing the functional construction of the exemplar directory service.  
         [0118]     As shown in  FIG. 7 , the directory service  40  includes a directory distribution part  41 , a directory distribution part  41 , a session managing part  42 , a directory provider A 43 , a directory provider B 44 , and an SOAP stub  45 .  
         [0119]     It should be noted that the SOAP stub  45  is a module for realizing communication between the client  3  and/or authentication service provider server by SOAP.  
         [0120]     The directory distribution part  41  is a module providing a common interface to various directory providers to the client  3  and/or the authentication service providing server  1 .  
         [0121]     The directory provider A 43 , the directory provider B 44 , and the like, are the module called “directory provider”. Here, it should be noted that the directory provider functions as an adapter or mediator for incorporating various directory engines into the directory service  40 . Furthermore, it should be noted that the directory engine means the system that provides management of user information or group information regarding the directory, and the like, and/or providing of such information.  
         [0122]     It should be noted that each directory engine has its own original interface (protocol). On the other hand, in order to provide the function of each directory engine to the client  3  as the Web service, there is a need to comply with the interface prescribed with regard to the directory distribution part  41 .  
         [0123]     It is the directory provider that absorbs the difference between the original protocols of the individual directory engines and provides a common interface to the directory distribution part  41 . Accordingly, in order to incorporate a new directory engine into the directory service  40 , a new directory provider has to be implemented. On the other hand, the directory provider itself may have the function of the directory engine.  
         [0124]     The session managing part  42  is the module that manages the session  70 .  
         [0125]     In  FIG. 7 , the functional construction of the directory provider  40  has been explained for the example that has plural directory providers. However, it is not necessary that the directory provider  40  has plural directory providers and may have the construction that has only the directory provider A 43 . In the case of such a construction, the directory distribution part  41  is not necessarily included in the construction of directory service  40 .  
         [0126]     However, for the sake of simplification of the explanation, following explanation will be made on the assumption that the directory service  40  has plural directory providers as shown in  FIG. 7  and the directory distribution part  41  is included in the directory service  40 . This, however, does not restrict the implementation of the present invention.  
         [0127]     Hereinafter, an example of the authentication ticket acquisition request will be explained by using  FIG. 8 .  
         [0128]      FIG. 8  is a diagram for explaining an example of the authentication ticket acquisition request.  
         [0129]     As shown in  FIG. 8 , the tag &lt;ProviderName&gt;&lt;/ProviderName&gt; of the authentication ticket acquisition request includes the provider name that distinguishes the authentication provider as a parameter.  
         [0130]     Also, the tag &lt;DomainName&gt;&lt;/DomainName&gt; includes the domain name as the parameter.  
         [0131]     Further, the tag &lt;AuthName&gt;&lt;/AuthName&gt; includes the user name as a parameter.  
         [0132]     Further, the tag &lt;Password&gt;&lt;/Password&gt; includes a password as a parameter.  
         [0133]     Further, the tag &lt;Duration&gt;&lt;/Duration&gt; includes the effective time of the authentication ticket  50  as a parameter in terms of seconds.  
         [0134]     For example, the SOAP stub  35  that has received the authentication ticket acquisition request shown in  FIG. 8  calls authenticateByPassword, which is the method that the authentication service  30  provides, while using the foregoing parameters as an argument.  
         [0135]     Then the authentication distribution part  31  provides the above-mentioned domain name, user name, password etc, to the corresponding authentication provider (such as authentication provider A 33 ) based on the provider name, and requests authentication.  
         [0136]     The authentication provider A 33  that has received the request of the authentication transmits the authentication request of the user including the domain name, user name, password etc., to an authentication server such as an external authentication server.  
         [0137]     For example, the authentication provider A 33  that has received the result of authentication indicating that the user is a valid user together with the group information to which that user belongs from the foregoing external authentication server, and the like, provides the received information, the password, the effective time of the authentication ticket  50 , and the like, to the ticket administration part  32  and requests creation of the authentication ticket  50 .  
         [0138]     The ticket managing part  32  that has received the above-mentioned request creates the authentication ticket  50  shown in  FIG. 10  to be described later and provides the authentication ticket ID, which is the distinction information distinguishing the authentication ticket  50 , to the authentication provider A 33  as the authentication ticket  50 .  
         [0139]     The authentication provider A 33  provides the above-mentioned authentication ticket ID to the authentication distribution part  31 .  
         [0140]     The authentication distribution part  31  calls authenticateByPasswordResponse, which is a method that the authentication service  30  provides, while using the authentication ticket ID, and the like, as the argument.  
         [0141]     Then, the SOAP stub  35  creates the authentication ticket acquisition response as shown in  FIG. 9  that contains the above-mentioned authentication ticket ID as will be described later and transmits the same to the client  3 .  
         [0142]     Hereinafter, an example of the authentication ticket acquisition response will be explained by using  FIG. 9 .  
         [0143]      FIG. 9  is a diagram for explaining the example of the authentication ticket acquisition response.  
         [0144]     As shown in  FIG. 9 , the tag &lt;Return xsi: type=‘xsd:’ base64Binary&gt;&lt;/Return&gt; of the authentication ticket acquisition response contains the above-mentioned authentication ticket ID.  
         [0145]     The client  3  that has acquired the foregoing authentication ticket ID creates the acquisition request of the Web service use ticket  60  that includes the authentication ticket ID and transmits the same to the authentication service  30  as will be described later.  
         [0146]     Hereinafter, the internal structure of an exemplary authentication ticket  50  will be explained by using  FIG. 10 .  
         [0147]      FIG. 10  is a diagram for explaining an example of the internal structure of an authentication ticket.  
         [0148]     As shown in  FIG. 10 , the authentication ticket  50  contains authentication ticket ID, provider name, term of validity, user information, group information, and password.  
         [0149]     It should be noted that the authentication ticket ID holds the distinction information for distinguishing the authentication ticket  50 . The provider name holds the name of the authentication provider that has made the authentication. The term of validity holds the term of validity of the authentication ticket  50  provided from the authentication provider that has made the authentication. Further, the user information holds the structure of the user information of the user provided from the authentication provider in the form as it is. The group information stores the arrangement of the pointer pointing to the structure of the group information of the group to which the user belongs and provided from the authentication provider that has made the authentication. The password holds the password provided from the authentication provider that has made the authentication.  
         [0150]     Hereinafter, an example of the user information structure will be explained by using  FIG. 11 .  
         [0151]      FIG. 11  is a diagram for explaining an example of the user information structure.  
         [0152]     As shown in  FIG. 11 , the user information structure contains the user ID, the domain name, and the name.  
         [0153]     The user ID holds the distinction information for distinguishing the user. The domain name holds the domain name corresponding to the above-mentioned user. The name holds the name of the above-mentioned user.  
         [0154]     Further, the user information structure may further include last name, name, nickname, display name, reading of the name, employee number, address, phone number, mail address, executive title, assigned organization, additional post information, accounting code, assigned group, manager authority, and the like.  
         [0155]     Hereinafter, an example of the group information structure will be explained by using  FIG. 12 .  
         [0156]      FIG. 12  is such a diagram for explaining the example of the group information structure.  
         [0157]     As shown in  FIG. 12 , the group information structure contains the group ID, the domain name, and the name.  
         [0158]     The group ID holds the distinction information for distinguishing the group to which the user belongs. The domain name holds the domain name corresponding to the group. Further, the name holds the name of the group.  
         [0159]     Furthermore, the group information structure may include group name, group explanation, upper class group, lower class group, group members, group code, accounting code, and the like.  
         [0160]     Hereinafter, an example of authentication ticket creation processing will be explained by using  FIG. 13 .  
         [0161]      FIG. 13  is a flowchart explaining an example of the authentication ticket creation processing.  
         [0162]     In step S 10 , the SOAP stub  35  receives an authentication ticket acquisition request shown in  FIG. 8  from the client  3 . As noted previously, the SOAP stub  35  that has received the authentication ticket acquisition request calls authenticateByPassword, which is a method provided by the authentication service  30 , while using each parameter included in the authentication ticket acquisition request as the argument.  
         [0163]     After the step S 10 , the process proceeds to the step S 11 , and the authentication distribution part  31  determines whether or not the provider name is a valid provider name on the basis of the provider name, which is one of the above-mentioned parameters.  
         [0164]     When it is determined that the provider name is a valid provider name (YES in step S 11 ), the authentication distribution part  31  provides the parameters such as the domain name, user name, password, and the like, to a corresponding authentication provider (for example, the authentication provider A 33 ), and requests the authentication.  
         [0165]     On the other hand, when it is determined that the provider name is not a valid provider name (NO in step S 11 ), the authentication distribution part  31  terminates the processing.  
         [0166]     For example, the authentication distribution part  31  holds and manages the name of the authentication provider and determines, based on the comparison of the provider name included in the parameter and the name of the authentication providers under possession and management, whether or not there exists a valid provider name that corresponds the given provider name.  
         [0167]     In the step S 12 , the authentication provider A 33  that has received the request for the above-mentioned authentication determines, when requesting the authentication of the user to an external authentication server, and the like, whether or not the external authentication server is in operation.  
         [0168]     When it is determined that the corresponding external authentication server is in operation (YES in step S 12 ), the authentication provider A 33  transmits an authentication request of the user including the domain name, user name, password etc., to the foregoing external authentication server.  
         [0169]     On the other hand, when it is determined that the corresponding external authentication server is in operation (NO in step S 12 ), the authentication provider A 33  terminates the processing.  
         [0170]     For example, the authentication provider A 33  strikes a ping (Packet. Internet Groper) to the corresponding external authentication server and determines whether or not the external authentication server is in operation.  
         [0171]     In the step S 13 , the authentication provider A 33  determines whether or not the authentication has been successful.  
         [0172]     When it has been determined that the authentication has been successful (YES in step S 13 ), the authentication provider A 33  provides the group information of the group to which the above-mentioned user belongs, the information of the user contained in the above-mentioned authentication ticket acquisition request, the effective time of the password and the authentication ticket  50 , and the like, received from the external authentication server, and the like, to the ticket managing part  32  and requests creation of the authentication ticket  50 .  
         [0173]     On the other hand, when it has been determined that the authentication has failed (NO in step S 13 ), the authentication provider A 33  terminates the processing.  
         [0174]     For example, the authentication provider A 33  determines that the authentication has been successful when it receives the authentication result indicating success of the authentication and the group information of the group to which the user belongs, and the like.  
         [0175]     In the step S 14 , the ticket managing part  32  thus received the creation request of the authentication ticket  50  crates the authentication ticket  50  shown in  FIG. 10  and provides the authentication ticket ID, which is the distinction information for distinguishing the authentication ticket  50  to the authentication provider A 33  as the authentication ticket  50 .  
         [0176]     After the step S 14 , the process proceeds to the step S 15  the authentication distribution part  31  that has been provided with the above-mentioned authentication ticket ID from the authentication provider A 33  calls authenticateByPasswordResponse, which is the method that the authentication service  30  provides, while using the above-mentioned authentication ticket ID, and the like, as the argument. Then SOAP stub  35  creates the authentication ticket acquisition response containing the above-mentioned authentication ticket ID shown in  FIG. 9  based on the request from the authentication distribution part  31 .  
         [0177]     After the step S 15 , the process proceeds to the step S 16 , and the SOAP stub  35  transmits the authentication ticket acquisition response created in step S 15  to the client  3 .  
         [0178]     Meanwhile, in the case of not using an external authentication server, and the like, and the authentication provider A 33  itself functions as an authentication engine, it is possible to omit the processing shown in the step S 12  and use the authentication provider A 33  itself to carry out the authentication and the processing of the step S 13  for determining whether or not the authentication has been successful.  
         [0179]     Hereinafter, an example of the Web service use ticket acquisition request will be explained by using  FIG. 14 .  
         [0180]      FIG. 14  is a diagram for explaining an example of the Web service use ticket acquisition request.  
         [0181]     As shown in  FIG. 14 . the tag &lt;MasterAuthTicket&gt;&lt;/masterAuthTicket&gt; of the Web service use ticket acquisition request includes the authentication ticket ID as a parameter.  
         [0182]     Further, the tag &lt;Duration&gt;&lt;/duration&gt; includes the term of validity of the Web service use ticket  60  as a parameter in terms of seconds.  
         [0183]     Also, the tag &lt;item&gt;&lt;/item&gt; includes the character sets (hereinafter designated simply as target) for distinguishing the Web service that the client request for the use thereof (such as directory service  40 ) as a parameter.  
         [0184]     For example, the SOAP stub  35  that has received the Web service use ticket acquisition request shown in  FIG. 14  calls createAuthTicket, which is a method that the authentication service  30  provides, while using each parameter as an argument.  
         [0185]     Then the authentication distribution part  31  determines whether or not there exists a valid authentication ticket  50  corresponding to that authentication ticket ID on the basis of the above-mentioned authentication ticket ID.  
         [0186]     When it is determined that there exists a valid authentication ticket  50  corresponding to the above-mentioned authentication ticket ID in the ticket administration part  32 , the authentication distribution part  31  acquires the provider name, and the like, included in the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID from the ticket management part  32  and provides the authentication ticket ID, the effective time of the above-mentioned Web service use ticket  60 , the target, and the like, to the authentication provider (for example, the authentication provider A 33 ) corresponding to the above-mentioned provider name.  
         [0187]     The authentication provider A 33  provides the authentication ticket ID, the term of validity of the Web service use ticket  60 , the target, and the like, to the ticket management part  32  and requests creation of the Web service use ticket  60 .  
         [0188]     The ticket managing part  32  that has received the foregoing request creates the Web service use ticket  60  shown in  FIG. 16  to be described later and provides the Web service use ticket ID, which is the distinction information that distinguishes the Web service use ticket  60 , to the authentication provider A 33  as the Web service use ticket  60 .  
         [0189]     In the case the tag &lt;item&gt;&lt;/item&gt; of the Web service use ticket acquisition request shown in  FIG. 14  contains nothing, the ticket managing part  32  may create a Web service use ticket  60  not having anything in the target of  FIG. 16  to be described later and thus can use any Web service, and provides the Web service use ticket ID, which is the distinction information that distinguishes that Web service use ticket  60 , to the authentication provider A 33  as the Web service use ticket  60 .  
         [0190]     In the explanation hereinafter, it is assumed for the sake of simplicity that the tag &lt;item&gt;&lt;/item&gt; of the Web service use ticket acquisition request includes the distinction information (for example, the character set such as repositoryservice) distinguishing the Web service (for example, directory service  40 ) that the client requests the use thereof.  
         [0191]     The authentication provider A 33  provides the above-mentioned Web service use ticket ID to the authentication distribution part  31 .  
         [0192]     The authentication distribution part  31  calls createAuthTicketResponse, which is a method that the authentication service  30  provides, while using the Web service use ticket ID, and the like, as the argument.  
         [0193]     Then the SOAP stub  35  creates the Web service use ticket acquisition response shown in  FIG. 15  that contains the Web service use ticket ID to be described later and transmits the same to the client  3 .  
         [0194]     Hereinafter, an example of the Web service use ticket acquisition response will be explained by using  FIG. 15 .  
         [0195]      FIG. 15  is a diagram explaining an example of the Web service use ticket acquisition response.  
         [0196]     As shown in  FIG. 15 , the tag &lt;Return xsi: type=‘xsd: base64Binary’&gt;&lt;/return&gt; of the Web service use ticket acquisition response includes the Web service use ticket ID.  
         [0197]     The client  3  that has acquired the Web service use ticket ID transmits a session start request including the Web service use ticket ID to the directory service  40 , as will be described later.  
         [0198]     Hereinafter, an example of the internal structure of the Web service use ticket  60  will be described by using  FIG. 16 .  
         [0199]      FIG. 16  is a diagram that explains an example of the internal structure of the Web service use ticket.  
         [0200]     As shown in  FIG. 16 , the Web service use ticket  60  contains the Web service use ticket ID, authentication ticket ID, target, and the term of validity.  
         [0201]     The Web service use ticket ID holds the distinction information that distinguishes the Web service use ticket  60 .  
         [0202]     The authentication ticket ID holds the distinction information distinguishing the authentication ticket  50  provided by the authentication provider (such as the authentication provider A 33 ). The target holds the character set distinguishing the Web service provided by the authentication provider (such as the authentication provider A 33 ). The term of validity holds the term of validity of the Web service use ticket  60  provided from the authentication provider (for example, authentication provider A 33 ).  
         [0203]     Further, it should be noted that the contents of the authentication ticket  50  shown in  FIG. 10  may be included in the Web service use ticket  60  as they are, in replace of the authentication ticket ID.  
         [0204]     Hereinafter, the concept figure of the data inside the ticket managing part  32  will be explained by using  FIG. 17 .  
         [0205]      FIG. 17  is the diagram showing the concept of the data inside the ticket managing part.  
         [0206]     As shown in  FIG. 17  the user information explained in  FIG. 11  is related to the authentication ticket  50  explained in  FIG. 10  in one to one correspondence.  
         [0207]     Further, the group information explained in  FIG. 12  is related to the authentication ticket  50  in one to n correspondence (n is a natural number equal to or larger than n). This reflects the situation in which the certified user does not belong to any of the groups or may belong to plural groups.  
         [0208]     Also, the Web service use ticket  60  explained in  FIG. 16  is related to the authentication ticket  50  in one to m correspondence (m is a natural number equal to or larger than 1). This reflects the situation that the Web service providing server  2  may provide plural Web services.  
         [0209]     Hereinafter, an example of the Web service use ticket creation processing will be explained by using  FIG. 18 .  
         [0210]      FIG. 18  is a flowchart for explaining an example of the Web service use ticket creation processing.  
         [0211]     In the step S 20 , the SOAP stub  35  receives the Web service use ticket acquisition request shown in  FIG. 14  from the client  3 . As mentioned above, the SOAP stub  35  that has received the Web service use ticket acquisition request calls createAuthTicket, which is a method that the authentication service  30  provides while using each parameter included in the Web service use ticket acquisition request as an argument.  
         [0212]     After the step S 20 , the process proceeds to the step S 21  and the authentication distribution part  31  determines whether or not there exists the authentication ticket  50  corresponding to that authentication ticket ID on the basis of the authentication ticket ID, which is one of the above-mentioned parameters. When it is determined in the Authentication distribution part  31  that the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID exists (YES in step S 21 ), the process proceeds to the step S 24 , while when it is determined that the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID does not exist (NO in step S 21 ), the process proceeds to step S 22 .  
         [0213]     For example, the authentication distribution part  31  submits inquiry to the ticket managing part  32  about whether or not there exists an authentication ticket  50  containing the above-mentioned authentication ticket ID and corresponding to that authentication ticket ID and determines that the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID exists in the case that the answer is given from the ticket managing part  32  indicating that the authentication ticket  50  exists.  
         [0214]     On the other hand, in the event there is provided an answer from the ticket managing part  32  indicating that the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID does not exist, authentication distribution part  31  determine that the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID does not exist.  
         [0215]     In the step S 22 , the authentication distribution part  31  calls a predetermined method that the authentication service  30  provides and requests creation of error message indicating that the corresponding authentication ticket  50  does not exist. The SOAP stub  35  creates an error message indicating that the corresponding authentication ticket  50  does not exist in correspondence to the above-mentioned request.  
         [0216]     Following the step S 22 , the process proceeds to the step S 23  and the SOAP stub  35  transmits the error message created in the step S 22  to the client  3  terminates the processing.  
         [0217]     On the other hand, in the step S 24 , the authentication distribution part  31  determines, on the basis of the above-mentioned authentication ticket ID, whether or not the term of validity of the authentication ticket  50  corresponding to the authentication ticket ID is over.  
         [0218]     When it is determined that the term of validity of the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID is not over (YES in step S 24 ), the authentication distribution part  31  acquires the provider name included in the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID from the above-mentioned authentication ticket ID on the basis of the ticket administration part  32 , and provides the above-mentioned authentication ticket ID, the effective time of the Web service use ticket  60 , the target, and the like, to the authentication provider corresponding to the provider name (for example, authentication provider A 33 ).  
         [0219]     The authentication provider A 33  provides the above-mentioned authentication ticket ID, the term of validity of the Web service use ticket  60 , the target, and the like, to the ticket managing part  32  and requests creation of the Web service use ticket  60 . Thereafter, the process proceeds to the step S 27 .  
         [0220]     On the other hand, when it is determined that the term of validity of the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID is over (NO in step S 24 ), the authentication distribution part  31  proceeds to the step S 25 .  
         [0221]     For example, the authentication distribution part  31  submits inquiry to the ticket managing part  32  as to whether or not the term of validity of the authentication ticket  50  containing the above-mentioned authentication ticket ID and corresponding to the authentication ticket ID is over, and determines that the term of validity of the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID is not over in the event the ticket managing part  32  provided the answer indicating that the term of validity of the authentication ticket  50  corresponding to the authentication ticket ID is over.  
         [0222]     On the other hand, the authentication distribution part  31  determines when the ticket managing part  32  provides an answer indicating that the term of validity of the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID is over, that the term of validity of the authentication ticket  50  corresponding to the above-mentioned authentication ticket ID is over.  
         [0223]     Next, in the step S 25 , the authentication distribution part  31  calls a predetermined method that the authentication service  30  provides, and requests creation of an error message indicating that the term of validity of the corresponding authentication ticket  50  is over. Then, the SOAP stub  35  creates the error message indicating that the term of validity of the corresponding authentication ticket  50  is over in response to the above-mentioned request.  
         [0224]     Next, the process proceeds from the step S 25  to the step S 26  and the SOAP stub  35  transmits the error message created in the step S 25  to the client  3  and terminates the processing.  
         [0225]     In the step S 27 , on the other hand, the ticket managing part  32  that has received the creation request of the above-mentioned Web service use ticket  60  creates the Web service use ticket  60  shown in  FIG. 16  and provides the Web service use ticket ID, which is the distinction information that distinguishes that Web service use ticket  60 , to the authentication provider A 33  as the Web service use ticket  60 .  
         [0226]     After the step S 27 , the process proceeds to the S 28  and the authentication distribution part  31  provided with the above-mentioned Web service use ticket ID from the authentication provider A 33  calls createAuthTicketResponse, which is a method that the authentication service  30  provides, while using the above-mentioned Web service use ticket ID as the argument. Then the SOAP stub  35  creates the Web service use ticket acquisition response including the above-mentioned Web service use ticket ID shown in  FIG. 15  based on the request from the authentication distribution part  31 .  
         [0227]     After the step S 28 , the process proceeds to the step S 29  and the SOAP stub  35  transmits the Web service use ticket acquisition response created in the step S 28  to the client  3  in response to the request from the authentication distribution part  31 .  
         [0228]     Furthermore, as shown in  FIG. 18 , the authentication service  30  transmits the error message indicating the authentication ticket  50  does not exist and the error message indicating that the term of validity of the authentication ticket  50  is over to the client  3  individually.  
         [0229]     For example, in the case that client  3  holds the password, and the like, once input by the user, the client  3 , upon reception of the error message indicating that the term of validity of the authentication ticket  50  is over from the authentication service  30 , can transmit the acquisition request of the authentication ticket  50  once again to the authentication service  30  by using the above-mentioned password.  
         [0230]     Furthermore, the authentication service  30  eliminates, when the elimination method that the authentication service  30  provides is called or when a predetermined period (for example, one hour after the authentication ticket  50  is created) has elapsed, the corresponding authentication ticket  50  Hereinafter, an example of the session start request will be explained by using  FIG. 19 .  
         [0231]      FIG. 19  is a diagram for explaining an example of the session start request.  
         [0232]     As shown in  FIG. 19 , the tag &lt;AuthTicket&gt;&lt;/authTicket&gt; of the session start request includes the Web service use ticket ID as a parameter.  
         [0233]     Also, the tag &lt;TimeLimit&gt;&lt;/timeLimit&gt; includes the valid time of the session  70  is included as a parameter in terms of second.  
         [0234]     For example, the SOAP stub  45  that has received the session start request shown in  FIG. 19  calls startSessionByAuthTicket, which is the method that the directory service  40  provides, while using each of the above-mentioned parameters as an argument.  
         [0235]     Then, the directory distribution part  41  calls decodeAuthTicket, which is a method that the directory service  40  provides while using the Web service use ticket ID and also the character set that the directory service  40  provides for distinguishing the service as arguments.  
         [0236]     Then the SOAP stub  45  creates a Web service use ticket decoding request including the above-mentioned Web service use ticket ID and also the character set for distinguishing the service that the directory service  40  provides as will be described later in  FIG. 21 , and transmits the same to the authentication service  30 .  
         [0237]     Furthermore, the information regarding the authentication service  30  (URL etc., for example) is acquired by the address directory distribution part  41  from the HDD 29  etc. and may be submitted to the SOAP stub  45  as the argument of method decodeAuthTicket. Alternatively, the client  3  may transmit the URL, and the like of the authentication service  30 , which is the destination of transmission of the Web service use ticket decoding request, in the form included in the session start request, to the directory service  40 , such that the directory distribution part  41  provides the URL of the authentication service  30  as an argument of the method decodeAuthTicket to the SOAP stub  45 .  
         [0238]     Hereinafter, another example of the session start request will be explained by using  FIG. 20 .  
         [0239]      FIG. 20  is a diagram that explains an example of other session start request.  
         [0240]     In the session start request shown in  FIG. 20 , the tag &lt;uauthenticationUrl&gt;&lt;/uauthenticationUrl&gt; includes the URL of the authentication service  30  as a parameter.  
         [0241]     The directory service  40  transmits the Web service use ticket decoding request shown in  FIG. 21  to be described later to the authentication service  30  based on the URL of the authentication service  30 .  
         [0242]     Further, although not illustrated, the client  3  man transmit the provider name of the directory provider in the form included in the session start request shown in  FIG. 19  and/or  FIG. 20 , to the directory service  40 . By using such a construction, the client  3  can designate the directory provider.  
         [0243]     Hereinafter, an example of the Web service use ticket decoding request will be explained by using  FIG. 21 .  
         [0244]      FIG. 21  is a diagram for explaining an example of the Web service use ticket decoding request.  
         [0245]     As shown in  FIG. 21 , the tag &lt;authTicket&gt;&lt;/authTicket&gt; of the Web service use ticket decoding request includes the Web service use ticket ID as a parameter.  
         [0246]     Also, the tag &lt;target&gt;&lt;/target&gt; includes the character set for distinguishing the service that the directory service  40  provides.  
         [0247]     For example, the SOAP stub  35  that has received the Web service use ticket decoding request shown in  FIG. 21  calls decodeAuthTicket, which is the method that the authentication service  30  provides, while using each of the above-mentioned parameters as an argument.  
         [0248]     Then, the authentication distribution part  31  determines whether or not there exists a valid Web service use ticket  60  corresponding to the above-mentioned Web service use ticket ID, whether or not the target included in the Web service use ticket  60  is identical to the character set for distinguishing the service provided by the directory service  40 , and the like, based on the above-mentioned Web service use ticket ID and/or the character set for distinguishing the service that the directory service  40  provides.  
         [0249]     When it is determined that there exists a valid Web service use ticket  60  corresponding to the above-mentioned Web service use ticket ID and that the target included in the Web service use ticket  60  and the character set for distinguishing the service that the above-mentioned directory service  40  provides are the same, the authentication distribution part  31  acquires the contents of the Web service use ticket  50  (except for authentication ticket ID) as shown in  FIG. 10  and/or the content of the authentication ticket  60  (except for Web service use ticket ID and authentication ticket ID) as shown in  FIG. 16  on the basis of the authentication ticket ID that is included in the corresponding Web service use ticket  60  and calls decodeAuthTicketResponse, which is a method that the authentication service  30  provides, while using such information and the result of determination to be described later as an argument.  
         [0250]     Then the SOAP stub  35  creates the Web service use ticket decoding response including the above-mentioned determination result, the contents of the authentication ticket  50  and/or the contents of the Web service use ticket  60 , and transmits the same to the directory service  40 .  
         [0251]     Hereinafter, an example of the Web service use ticket decoding response will be explained by using  FIG. 22 .  
         [0252]      FIG. 22  is a diagram for explaining an example of the Web service use ticket decoding response.  
         [0253]     As shown in  FIG. 22 , the tag of the Web service use ticket decoding response &lt;return xsi: type=‘xsd: string’&gt;&lt;/return&gt; includes the result of the determination.  
         [0254]     With regard to the result of the determination, OK is included in the foregoing tag in the event for example there exists a valid Web service use ticket  60  corresponding to the Web service use ticket ID included in the above-mentioned Web service use ticket decoding request and the target included in the Web service use ticket  60  is identical to the character set for distinguishing the service that the directory service  40  included in the above-mentioned Web service use ticket decoding request provides.  
         [0255]     On the other hand, in the case there exists no valid Web service use ticket  60  corresponding to the Web service use ticket ID included in the above-mentioned Web service use ticket decoding request, or in the case the target included in the above-mentioned Web service use ticket  60  is not the same as the character set for distinguishing the service provided by the directory service  40  contained in the above-mentioned Web service use ticket decoding request, NO is written to the above-mentioned tag.  
         [0256]     Furthermore, the Web service use ticket decoding response may include the contents of authentication ticket  50  (except for authentication ticket ID) and/or the contents of the Web service use ticket  60  (except for Web service use ticket ID and authentication ticket ID) as noted above.  
         [0257]     The SOAP stub  45  that has received the Web service use ticket decoding response as shown in  FIG. 22 , for example, provides the valid time, and the like, of the above-mentioned Web service use ticket ID and also the above-mentioned session  70  to the corresponding directory provider (for example, directory provider A 43 ) on the basis of the provider name included the Web service use ticket decoding response.  
         [0258]     Furthermore, in the case that a provider name of a directory provider is included in the session start request, it is possible to provide the above-mentioned Web service use ticket ID and the valid time, and the like, of and the above-mentioned session  70  to the corresponding directory provider (for example, directory provider A 43 ) based on the provider name.  
         [0259]     The directory provider A 43  provides the above-mentioned Web service use ticket ID and the valid time, and the like, of the above-mentioned session  70  to the session managing part  42  and requests creation of the session  70 .  
         [0260]     The session managing part  42  that has received the above-mentioned request creates the session  70  shown in  FIG. 24  to be described later and provides the session ID, which is the distinction information for distinguishing the session  70 , to the directory provider A 43  as the session  70 .  
         [0261]     The directory provider A 43  provides the above-mentioned session ID to the directory distribution part  41 .  
         [0262]     The Directory distribution part  41  calls startSessionByAuthTicketResponse, which is the method that directory service  40  provides, while using the above-mentioned session ID, and the like, as the argument.  
         [0263]     Then the SOAP stub  45  creates the session start response shown in  FIG. 23  that contains the above-mentioned session ID as will be described later and transmits the same to the client  3 .  
         [0264]     Hereinafter, an example of the session start response will be explained by using  FIG. 23 .  
         [0265]      FIG. 23  is a diagram for explaining an example of the session start response.  
         [0266]     As shown in  FIG. 23 , the tag &lt;returnValue xsi: type=‘xsd: string’&gt;&lt;/returnValue&gt; of the session start response includes the above-mentioned session ID.  
         [0267]     For example, the client  3  that has acquired the session ID transmits the directory service use request including that session ID to the directory service  40 , as will be described later.  
         [0268]     Hereinafter, an example of the internal structure of session  70  will be explained by using  FIG. 24 .  
         [0269]      FIG. 24  is a diagram for explaining an example of the internal structure of the session.  
         [0270]     As shown in  FIG. 24 , the session  70  includes the session ID, the Web service use ticket ID, and the term of validity.  
         [0271]     The session ID holds the distinction information that distinguishes the session  70 . The Web service use ticket ID holds the distinction information for distinguishing the Web service use ticket  60  provided from the directory provider (for example, directory provider A 43 ). The term of validity of session holds the term of validity  70  provided from the directory provider (for example, directory provider A 43 ).  
         [0272]     Hereinafter, an example of the session creation processing will be explained by using  FIG. 25 .  
         [0273]      FIG. 25  is a flowchart for explaining an example of the session creation processing.  
         [0274]     In the step S 30 , the SOAP stub  45  receives a session start request shown in  FIG. 19  from the client  3 .  
         [0275]     As mentioned above, the SOAP stub  45  that has received the session start request calls startSessionByAuthTicket, which is a method that the directory service  40  provides, while using the Web service use ticket ID included in the session start request or the parameter of the valid time, and the like, of the session  70  as the arguments.  
         [0276]     Then the directory distribution part  41  calls decodeAuthTicket, which is a method that the directory service  40  provides, while using the Web service use ticket ID and the character set for distinguishing the service that the directory service  40  provides.  
         [0277]     Next, the process proceeds from the step S 30  to the step S 31  and the SOAP stub  45  creates the Web service use ticket decoding request shown in  FIG. 21  that includes the above-mentioned Web service use ticket ID and the character set for distinguishing the service that the directory service  40  provides, and transmits the same to the authentication service  30 .  
         [0278]     After the step S 31 , the process proceeds to the step S 32  and the SOAP stub  45  receives the Web service use ticket decoding response shown in  FIG. 22  from the authentication service  30 . As mentioned above, the SOAP stub  45  that has received the Web service use ticket decoding response calls decodeAuthTicketResponse, which is a method that the directory service  40  provides, while using the decoding result included in the Web service use ticket decoding response (referred to hereinafter as determination result), the contents of the authentication ticket  50  (except for authentication ticket ID) and/or the contents of the Web service use ticket  60  (except for Web service use ticket ID and authentication ticket ID) as the arguments.  
         [0279]     After the step S 32 , the process proceeds to the step S 33 , and the directory distribution part  41  determines whether or not the Web service use ticket ID that has been transmitted to authentication service  30  in the form included in the Web service use ticket decoding request in the step S 31  is the Web service use ticket ID of a valid Web service use ticket  60 .  
         [0280]     When it is determined that the above-mentioned Web service use ticket ID is the Web service use ticket ID of a valid Web service use ticket  60  (YES in step S 33 ),  
         [0281]     The directory distribution part  41  provides the effective time, and the like, of the above-mentioned Web service use ticket ID and also above-mentioned session  70  to the corresponding directory provider (for example, directory provider A 43 ), on the basis of the provider name contained in the Web service use ticket decoding response.  
         [0282]     The directory provider A 43  provides the above-mentioned Web service use ticket ID and the valid time, and the like, of the above-mentioned session  70  to the session managing part  42  and requests creation of the session  70 . Thereafter, the process proceeds to the step S 34 .  
         [0283]     On the other hand, directory distribution part  41  determines the processing when it is determined that the above-mentioned Web service use ticket ID is not the Web service use ticket ID of a valid Web service use ticket  60  (NO in step S 33 ).  
         [0284]     Furthermore, in the case the above-mentioned Web service use ticket ID has been determined as not being the Web service use ticket ID of a valid Web service use ticket  60 , the directory distribution part  41  may call a predetermined method that the directory service  40  provides and creates an error message indicating that the Web service use ticket ID was not the Web service use ticket ID of a valid Web service use ticket  60  and transmit the same to the client  3 .  
         [0285]     For example, the directory distribution part  41  determines, in the case the parameter OK is contained in the Web service use ticket decoding response that has been received in the step S 32 , that it is a Web service use ticket ID of a valid Web service use ticket  60 , while in the case the Web service use ticket decoding response has included the parameter NO, it determines that the Web service use ticket ID is a Web service use ticket ID of an invalid Web service use ticket  60 .  
         [0286]     Next, in the step S 34 , the session managing part  42  creates the session  70  as shown in  FIG. 24  and provides the session ID, which is the distinction information for distinguishing the session  70 , to the to directory provider A 43  as the session  70 .  
         [0287]     After the step S 34 , the process proceeds to the step S 35  and the directory distribution part  41  provided with the above-mentioned session ID from the directory provider A 43  calls startSessionByAuthTicketResponse while using the above-mentioned session ID, and the like, as the argument. Then the SOAP stub  45  creates the session start response including the session ID as shown in  FIG. 23  on the basis of the request from the directory distribution part  41 .  
         [0288]     After the step S 35 , the process proceeds to the step S 36  and the SOAP stub  45  transmits the session start response that has been created in the step S 35  on the basis of the request from the directory distribution part  41 , to the client  3 .  
         [0289]     Hereinafter, an example of the Web service use ticket decoding processing will be explained by using  FIG. 26 .  
         [0290]      FIG. 26  is a flowchart for explaining an example of the Web service use ticket decoding processing.  
         [0291]     In the step S 40 , the SOAP stub  35  receives the Web service use ticket decoding request shown in  FIG. 21  from the directory service  40 . As mentioned above, the SOAP stub  35  that has received the Web service use ticket decoding request calls decodeAuthTicket, which is a method that the authentication service  30  provides, while using parameters such as the Web service use ticket ID included in the Web service use ticket decoding request or the character set for distinguishing the service that the directory service  40  provides as the argument.  
         [0292]     After the step S 40 , the process proceeds to the step S 41  and the authentication distribution part  31  determines whether or not the Web service use ticket ID is a valid Web service use ticket ID, on the basis of the Web service use ticket ID, which is one of the foregoing parameters.  
         [0293]     When the authentication distribution part  31  has determined that the above-mentioned Web service use ticket ID is correct (YES in step S 41 ), the process proceeds to the step S 42 , while when it is determined that the Web service use ticket ID is not correct (No in step S 41 ), the process proceeds to the step S 45 .  
         [0294]     For example, the authentication distribution part  31  submits inquiry to the ticket managing part  32  about whether or not there exists a valid Web service use ticket  60  corresponding to the Web service use ticket ID including the above-mentioned Web service use ticket ID, and in the case there was given the answer from the ticket administration part  32  indicating that there exists a corresponding valid Web service use ticket  60 , the authentication distribution part  31  determines that it is a correct Web service use ticket ID.  
         [0295]     On the other hand, when there was given an answer from the ticket managing part  32  indicating that there exists no valid Web service use ticket  60  corresponding to the above-mentioned Web service use ticket ID, the authentication distribution part  31  determines that it an incorrect Web service use ticket ID.  
         [0296]     In the step S 42 , the authentication distribution part  31  determines whether or not the character set, which is one of the above-mentioned parameters, for distinguishing the service that the directory service  40  provides agrees with the character set of the target contained in the service use ticket  60  corresponding to the above-mentioned Web service use ticket ID.  
         [0297]     When it is determined in the authentication distribution part  31  that the above-mentioned two character sets agree to each other (YES in step S 42 ), the process proceeds to the step S 43 , while in the case it is determined that the two character sets do not agree to each other (NO in step S 42 ), the process proceeds to the step S 45 .  
         [0298]     In the step S 43 , the authentication distribution part  31  acquires, based on the above-mentioned Web service use ticket ID, the contents of the corresponding Web service use ticket  60  (except for authentication ticket ID) and/or the contents of the authentication ticket  50  (except for the Web service use ticket ID and the authentication ticket ID) and calls decodeAuthTicketResponse, which is the method that the authentication service  30  provides while using these information and the determination result (YES) as the arguments.  
         [0299]     Then the SOAP stub  35  creates the Web service use ticket decoding response including the result of the above-mentioned determination (YES) and the contents of the authentication ticket  50  and/or the contents of the Web service use ticket  60 , and the like.  
         [0300]     After the step S 43 , the process proceeds to the step S 44  and the SOAP stub  35  transmits the Web service use ticket decoding response created in the step S 43  to the directory service  40 .  
         [0301]     On the other hand, in the step S 45 , the authentication distribution part  31  calls decodeAuthTicketResponse, which is the method that the authentication service  30  provides, while using g the result of the determination (NO) as the argument.  
         [0302]     Then, the SOAP stub  35  creates the Web service use ticket decoding response including the result of the above-mentioned determination (NO), and the like.  
         [0303]     After the step S 45 , the process proceeds the to step S 46  and the SOAP stub  35  transmits the Web service use ticket decoding response created in the step S 45  to the directory service  40 .  
         [0304]     As shown in  FIG. 25  and  FIG. 26 , the directory service  40  transmits the distinction information of itself (for example, the character set of repositoryService, and the like) to the authentication service  30  together with the Web service use ticket ID included in the request from the client  3 . On the other hand, the authentication service  30  determines the validity of the Web service use ticket  60  by comparing the distinction information (for example, the character set of repositoryservice etc.) transmitted from the directory service  40  and the target contained in the Web service use ticket  60  on the basis of the above-mentioned Web service use ticket ID.  
         [0305]     By using such authentication method, it becomes possible to provide the service of authentication efficiently without setting up new information, and the like, in the authentication service provider server  1  and/or the authentication service  30 , even in the case a new Web service that the client  3  uses and requires authentication is added to the Web service providing server  2 , and the like.  
         [0306]     In the step S 43  of  FIG. 26 , explanation has been given for the case in which the authentication distribution part  31  acquires, on the basis of the above-mentioned Web service use ticket ID, the contents of corresponding the Web service use ticket  60  (except for the Web service use ticket ID and the authentication ticket ID) and/or the contents of authentication ticket  50  (except for the authentication ticket ID), while the authentication distribution part  31  may acquire, on the basis of the above-mentioned Web service use ticket ID, only the corresponding provider name from the ticket administration department  32 , and requires acquisition of the contents of the Web service use ticket  60  corresponding to the above-mentioned Web service use ticket ID and/or the contents authentication ticket  50  to the provider corresponding to the provider name (for example, authentication provider A 33 ).  
         [0307]     In this case, the authentication provider A 33  that has received the request provides the request to the ticket managing part  32 . Te ticket managing part  32  that has received the request acquires, on the basis of the Web service use ticket ID included in the request, the contents of the corresponding Web service use ticket  60  (except for Web service use ticket ID and authentication ticket ID) and/or the contents of the authentication ticket  50  (except for authentication ticket ID), and provides the same to the authentication provider A 33 . The authentication provider A 33  provides the contents of the Web service use ticket  60  (except for Web service use ticket ID and also authentication ticket ID) and/or the contents of the authentication ticket  50  (except for authentication ticket ID) thus acquired to the authentication distribution part  31 .  
         [0308]     Hereinafter, an example of the directory service use request will be explained by using  FIG. 27 .  
         [0309]      FIG. 27  is a diagram for explaining an example of the directory service use request.  
         [0310]     As shown in  FIG. 27 , the tag &lt;sessionId&gt;&lt;/sessionId&gt; of the directory service use request contains the session ID as a parameter.  
         [0311]     The directory service  40  determines whether or not the session ID included in the directory service use request is a valid session ID, and when it is determined that it is a valid session ID, and acquires the user list according to the request of the client  3 . Further, the directory service  40  creates the directory service use response shown in  FIG. 28  to be described later and transmits the same to the client  3 .  
         [0312]     Hereinafter, an example of the directory service use response will be explained by using  FIG. 28 .  
         [0313]      FIG. 28  is a diagram for explaining an example of the directory service use response.  
         [0314]     Each of the tags included in the tag &lt;item&gt;&lt;/item&gt; of the directory service use response shown in  FIG. 28  contains information regarding the user list.  
         [0315]     Hereinafter, an example of the user list acquisition processing will be explained by using  FIG. 29 .  
         [0316]      FIG. 29  is a flowchart showing an example of the user list acquisition processing.  
         [0317]     In the step S 50 , the SOAP stub  45  receives from the client  3  the directory service use request shown in  FIG. 27 . The SOAP stub  45  that has received the directory service use request calls getEntryList, which is the method that the directory service  40  provides while using each of the parameters included in the directory service use request as the argument.  
         [0318]     After the step S 50 , the process proceeds to the step S 51  and the directory distribution part  41  determines whether or not the session ID, which is one of the parameters contained in the above-mentioned directory service use request, is a valid session ID.  
         [0319]     When it is determined the session ID is a valid session ID (YES in step S 51 ), the directory distribution part  41  proceeds to the step S 52 , while when it is determined that the session ID is not a valid session ID (NO in step  52 ), the processing is terminated.  
         [0320]     In the case it is determined the session ID is not a valid session ID, the directory distribution part  41  may create an error message indicating the same and transmit the same to the client  3 .  
         [0321]     For example, the directory distribution part  41  submit inquiry to the session managing part  42  by using the session ID included in the directory service use request whether or not there exists the session  70  including the session ID corresponding to the above-mentioned session ID and/or whether or not the term of validity of the session  70  that includes the corresponding session ID is over.  
         [0322]     When a response indicating that there exists such a session ID and/or the term of validity of the session  70  including the corresponding session ID is not over is acquired from the session managing part  42 , the directory distribution part  41  determines that this is a valid session ID.  
         [0323]     In the step S 52 , the corresponding directory provider (for example, directory provider A 43 ) acquires the user list.  
         [0324]     Following the step S 52 , the process proceeds to the Step S 53  the directory distribution part  41  that has been provided with the above-mentioned user list from the directory provider A 43  calls getEntryListResponse, which is a method that the directory service  40  provides, while using the user list as the argument. Then SOAP stub  45  creates, based on the request from the directory distribution part  41 , the directory service use response that contains the above-mentioned user list shown in  FIG. 28 .  
         [0325]     Following the step S 53 , the process proceeds to the step S 54  and the SOAP stub  4 . 5  transmits the directory service use response created in the step S 53  to the client  3 .  
         [0326]     Hereinafter, another example of the authentication service providing method and/or Web service providing method will be explained by using  FIG. 30 .  
         [0327]     For example, in the authentication service providing method and/or Web service providing method of  FIG. 5 , explanation has been made for the case the client knows, when using a Web service (for example, directory service  40 ), as to what authentication service the request for authentication should be submitted or the URL of that authentication service or the distinction information (for example, the character set of repositoryservice etc.) for distinguishing the directory service  40 , which becomes necessary when using the directory service  40 .  
         [0328]     In  FIG. 30  -shown below, explanation will be made for the example in which the client  3  inquires the URL of the authentication service that becomes necessary when using the director service  40  and the distinction information for distinguishing the directory service  40 .  
         [0329]      FIG. 30  is a second sequence diagram of explaining the authentication service providing method and/or Web service providing method.  
         [0330]     As shown in  FIG. 30 , the client  3  that uses the Web service that the Web service providing server  2  provides (such as directory service  40 ) transmits an acquisition request (information acquisition request) to the directory service  40  for the information related to the authentication server that carries out the authentication (for example, URL of the authentication service, and the like) and/or the distinction information (for example, character set of repositoryservice, and the like) for distinguishing the directory service, which becomes necessary for using the directory service  40  (sequence SQ 20  of  FIG. 30 ).  
         [0331]     The directory service  40  creates, in response to the above-mentioned information acquisition request from the client  3 , an information acquisition response that includes: the URL of the authentication service  30  that provides the service regarding authentication and becomes necessary when using the directory service  40  and/or the character set such as repositoryservice, which becomes necessary when using the directory service  40  for distinguishing the directory service  40 , and transmits the same to the client (sequence SQ 21  of  FIG. 30 ).  
         [0332]     In the case of such a construction, the directory service  40  holds and manages the URL of the authentication service  30  that provides the service related to the authentication and becomes necessary at the time of using the directory service  40  and/or the character set of repositoryservice etc., which distinguishes the directory service  40  needed at the time of using the directory service  40 .  
         [0333]     The client  3  that has received the above-mentioned information acquisition response creates that the acquisition request of the authentication ticket  50  that certifies the user of the client  3  on the basis of the URL of the authentication service  30  included in the acquisition response, and transmits the same to the certification service  30  (sequence SQ 22  of  FIG. 30 ).  
         [0334]     The authentication service  30  carries out the authentication on the basis of the user name, password etc. included in the authentication ticket acquisition request from the client  3  and creates the authentication ticket  50  including the ID of the authentication ticket  50  (authentication ticket ID) and transmits the same to the client  3  (sequence SQ 23  of  FIG. 30 ).  
         [0335]     The client  3  transmits, when the authentication ticket acquisition response is received, the acquisition request of Web service use ticket  60 , which includes the authentication ticket ID and the character set such as repositoryservice that distinguishes the directory service  40  acquired from the directory service  40  in the sequence SQ 21  and transmits the same to the authentication service  30  (sequence SQ 24  of  FIG. 30 ).  
         [0336]     The processing from the sequence SQ 25  to the sequence SQ 31  of  FIG. 30  is similar to the processing from the sequence SQ 4  to the sequence SQ 10  of  FIG. 5 .  
         [0337]     As shown in  FIG. 30 , as a result that the Web service (for example, directory service  40 ) holds and manages the information related to the authentication service  30  (for example, the URL etc. of the authentication service) and/or the distinction information that distinguishes the directory service  40  (for example, the character set of repositoryservice etc.), the client  3  can acquire the above-mentioned information merely by inquiring to the directory service  40 , and the like, even in the case of not knowing URL of the authentication service  30  and/or the character set of the repositoryservice, and the like, distinguishes the directory service  40 .  
         [0338]     Further, it is possible, in the processing one step before the processing of  FIG. 30 , to transmit, in the case that the client  3  does not know the URL etc. of the Web service (for example, directory service  40 ) to be used, a search request for the URL of the directory service to a discovery service, and the like, which carries out searching of the Web service, and the like, and to transmit an information acquisition request to the directory service  40  like the sequence SQ 20  shown in  FIG. 30  while using the URL of the directory service  40  acquired from the discovery service.  
         [0339]     In the case of such a construction, the client  3  can carry out the processing shown in  FIG. 30 , even in the case it does not know the URL, and the like, of the Web service to be used (for example, directory service  40 ), by acquiring the URL of the directory service  40 , and the like, by using the discovery service.  
         [0340]     Such a discovery service may be implemented in the authentication service providing server  1  or in the Web service providing server  2 , or in a different server, and the like, or in the same server (apparatus) and the like, to the authentication service  30  and the directory service  40 .  
       EMBODIMENT 2  
       [0341]     In the embodiment 2, explanation will be made for the case in which there exist plural (two, for example) Web services other than the authentication service  30 . Furthermore, the explanation of the second embodiment may be focused to the points different from the points explained in the embodiment 1.  
         [0342]      FIG. 31  is a sequence diagram for explaining the example of the authentication service providing method and/or the Web service providing method for the case in which there exist plural Web services.  
         [0343]     As shown in  FIG. 31 , the client  3  that uses the service that a Web service  80  (referred to hereinafter also as Web service (target ABC)  80 ) distinguished by the target ABC provides, creates an acquisition request for the authentication ticket  50  that certifies the user of the client  3  and transmits the same to the authentication service  30  (sequence SQ 50  of  FIG. 31 ).  
         [0344]     The authentication service  30  carries out the authentication on the basis of the user name, password, and the like, included in the authentication ticket acquisition request from the client  3 , and creates the authentication ticket  50 . Further, it creases an authentication ticket acquisition response including the ID (authentication ticket ID) of that authentication ticket  50  and transmits the same to the client  3  (sequence SQ 51  of  FIG. 31 ).  
         [0345]     The client  3  creates, upon reception of the authentication ticket acquisition response, an acquisition request of the Web service use ticket  60  that permits use of the Web service (target ABC)  80  including the above-mentioned authentication ticket and the distinction information that distinguishes the Web service that the Web service (target ABC)  80  to be used requests (ABC in the example of  FIG. 31 ) and transmits the same to the authentication service  30  (sequence SQ 52  of  FIG. 31 ).  
         [0346]     Here, it is assumed that the client  3  has inquired to the Web service (target ABC)  80 , for example in advance and has acquired already that the distinction information for distinguishing the Web service that the Web service (target ABC)  80  requests is ABC.  
         [0347]     The authentication service  30  determines, on the basis of the authentication ticket ID contained in the Web service use ticket acquisition request, whether or not there exists a valid corresponding authentication ticket  50 , and when it is determine that there exists a corresponding valid authentication ticket  50 , creates a Web service use ticket  60  including the distinction information (ABC in the example of  FIG. 31 ) that distinguishes the Web service contained in the above-mentioned Web service use ticket acquisition request. Further, the authentication service  30  creates the Web service use ticket acquisition response including the ID of the Web service use ticket  60  (Web service use ticket ID) and transmit the same to the client  3  (sequence SQ 53  of  FIG. 31 ).  
         [0348]     Upon reception of the Web service use ticket acquisition response, the client  3  creates the use request of the service that the Web service (target ABC)  80  provides including the Web service use ticket ID, and transmits the same to the Web service (target ABC)  80  (sequence SQ 54  of  FIG. 31 ).  
         [0349]     Here, it should be noted that the client  3  may transmit the session start request to the Web service as explained in embodiment 1 and transmit the service use request including the session ID, and the like, to the Web service, after the session with the Web service has been established. However, as shown in  FIG. 31 , it is possible to transmit the use request of the service including a direct Web service use ticket ID to the Web service without establishing the session. The same applies also in the description hereinafter. Also, this applies to the embodiment 1.  
         [0350]     The Web service (target ABC)  80  creates a decoding request of the Web service use ticket  60  including the Web service use ticket ID and the distinction information that distinguishes the Web service (target ABC)  80  (ABC in the example of  FIG. 31 ) on the basis of the Web service use ticket ID included in the use request of the service, and transmits the same to the authentication service  30  (sequence SQ 55  of  FIG. 31 ).  
         [0351]     When it is determined that there exists a valid Web service use ticket  60  corresponding to the Web service use ticket ID included in the decoding request of the Web service use ticket  60 , and that the distinction information included in the Web service use ticket  60  (ABC in the example of  FIG. 31 ) and the distinction information (ABC in the example of  FIG. 31 ) that distinguishes the Web service (target ABC)  80  contained in the decoding request of the Web service use ticket  60  are the same, the authentication service  30  creates a Web service use ticket decoding response including the determination result (O.K. in the example of  FIG. 31 ) and the contents of authentication ticket  50  and/or the contents of the Web service use ticket  60 , and the like, and transmits the same to the Web service (target ABC)  80  (sequence SQ 56  of  FIG. 31 ).  
         [0352]     The Web service (target ABC)  80  executes, on the basis of the determination result (O.K. in the example of  FIG. 31 ) contained in the Web service use ticket decoding response the processing corresponding to the use request of the service that has been received in the sequence SQ 54 , creates a service use response, and transmits the same to the client  3  (Sequence SQ 57  of  FIG. 31 ).  
         [0353]     Here, the processing for the case in which the Web service (target ABC)  80  is a malicious Web service and has attempted to use a service provided by a Web service  90  distinguished by the target DEF (hereinafter designated also as Web service (target DEF)  90 ) by using the Web service use ticket ID that permits the use of the Web service (target ABC)  80  included in the user request of the service received in the sequence SQ 54  will be explained by using the sequence SQ 58  through SQ 61 .  
         [0354]     The Web service (target ABC)  80  transmits a use request for the service that the Web service (target DEF)  90  provides, which includes the Web service use ticket ID included in the use request of the service received in the sequence SQ 54 , to the Web service (target DEF)  90  (sequence SQ 58  of  FIG. 31 ).  
         [0355]     The Web service (target DEF)  90  creates a decoding request of the Web service use ticket  60  including the Web service use ticket ID and the distinction information that distinguishes the Web service (target DEF)  90  (DEF in the example of  FIG. 31 ) on the basis of the Web service use ticket ID that is included in the use request of the service, and transmits the same to the authentication service  30  (sequence SQ 59  of  FIG. 31 ).  
         [0356]     When it is determined that although there exists a valid Web service use ticket  60  corresponding to the Web service use ticket ID included in the decoding request of the Web service use ticket  60  but the distinction information included in that Web service use ticket  60  (ABC in the example of  FIG. 31 ) and the distinction information included in the decoding request of the Web service use ticket  60  and distinguishes the Web service (target DEF)  90  included in the Web service use ticket  60  are different, the authentication service  30  creates a Web service use ticket decoding response including the determination result (NG in the example of  FIG. 31 ) and transmits the same to the Web service (target DEF)  90  (sequence SQ 60  of  FIG. 31 ).  
         [0357]     The Web service (target DEF)  90  creates a service use response, on the basis of the determination result included in the Web service use ticket decoding response (NG in the example of FIG.  31 ), including the error information indicating that the decoding has failed, and transmits the same to the Web service (target ABC)  80  (sequence SQ 61  of  FIG. 31 ).  
         [0358]     As shown in  FIG. 31 , the malicious Web service (target ABC)  80  cannot use, in the authentication service providing method and/or the Web service providing method of the present invention, the service that the Web service (target DEF)  90  provides even if it has attempted to do such conduct by using the Web service use ticket ID that permits the use of itself, because of the difference in the target (distinction information). Thus, even when a ticket or a ticket ID, or the like, on the communication route has been stolen, this cannot be used for the use of other Web services.  
         [0359]     Also, as mentioned above, it is not necessary to change the setting of the authentication service  30  and the client  3  in the authentication service providing method and/or the Web service providing method regarding the present invention, even in the case a new Web service is added to the system.  
         [0360]     It should be noted that the Web service (target ABC)  80  and the Web service (target DEF)  90  shown in  FIG. 31  may be implemented in the same Web service providing server  2  or in different Web service providing servers  2 .  
       EMBODIMENT 3  
       [0361]     In embodiment 3, explanation will be made for the case in which creation of the Web service use ticket  60  is requested and the services other than the acquired service use the Web service use ticket  60  (or Web service use ticket ID). The embodiment 3 may be focused on the points different from those of the embodiments 1 and 2.  
         [0362]      FIG. 32  is a sequence diagram of the authentication service providing method and/or the Web service providing method for the case other Web service uses the Web service use ticket.  
         [0363]     As shown in  FIG. 32 , the client  3  that is going to carry out printing of a document managed in the directory service  40 , which is distinguished by the target ABC, creates an acquisition request of the authentication ticket  50  authenticating the user of the client  3  and transmits the same to the authentication service  30  (sequence SQ 80  of  FIG. 32 ).  
         [0364]     The authentication service  30  carries out authentication based on the user name, password, and the like, included in the authentication ticket acquisition request from the client  3  and crates the authentication ticket  50 . Further, the authentication service  30  creates an authentication ticket acquisition response including the ID (authentication ticket ID) of the authentication ticket  50  and transmits the same to the client (sequence SQ 81  of  FIG. 32 ).  
         [0365]     Upon reception of the authentication ticket acquisition response, the client  3  creates an acquisition request for the directory service  40  including the above-mentioned authentication ticket ID and the distinction information distinguishing the directory service  40  that the directory service  40  for document management requests (ABC in the example of  FIG. 32 ), and transmits the same to the authentication service  30  (sequence SQ 82  of  FIG. 32 ).  
         [0366]     The authentication service  30  determines, on the basis of the authentication ticket ID contained in the Web service use ticket acquisition request, whether or not there exists a valid authentication ticket  50 , and when it is determined that there exists a corresponding valid authentication ticket  50 , the authentication service  30  crates a Web service use ticket  60  including the distinction information (ABC in the example of  FIG. 32 ) for distinguishing the Web service included in the Web service use ticket acquisition request. Further, the authentication service  30  creates a Web service use acquisition response including the ID of that Web service use ticket  60  (Web service use ticket ID) and transmits the same to the client  3  (sequence SQ 83  of  FIG. 32 ).  
         [0367]     Upon reception of the Web service use ticket acquisition response, the client  3  creates a printing request including the above-mentioned Web service use ticket ID and the document distinction information that distinguishes the document to be printed and transmits the same to a printing service  100  that provides the service of printing (Sequence SQ 84  of  FIG. 32 ).  
         [0368]     Upon reception of the printing request, the printing service  100  creates a document access request that contains the Web service use ticket ID included in the printing request and a document distinction information, and transmits the same to the directory service  40  (sequence SQ 85  of  FIG. 32 ).  
         [0369]     The directory service  40  creates, when the document access request is received, a decoding request of the Web service use ticket  60  that contains the Web service use ticket ID included in the document access request and the distinction information (ABC in the example of  FIG. 32 ) that distinguishes the directory service  40  and transmits the authentication service  30  (sequence SQ 86  of  FIG. 32 ).  
         [0370]     The authentication service  30  creates, in the case there exists a valid Web service use ticket  60  corresponding to the Web service use ticket ID included in the decoding request of the Web service use ticket  60  and it is determined that the distinction information included in that Web service use ticket  60  (ABC in the example of  FIG. 31 ) and the distinction information (ABC in the example of  FIG. 32 ) that distinguishes directory service  40  and contained in the decoding request of the Web service use ticket  60  are the same, creates a Web service use ticket decoding response including the determination result (O.K. in the example of  FIG. 32 ), the contents of authentication ticket  50  and/or the contents of Web service use ticket  60 , and transmits the same to the directory service  40  (sequence SQ 87  of  FIG. 32 ).  
         [0371]     The directory service  40  acquires, when the Web service use ticket decoding response is received, the document (or document contents) corresponding to the document distinction information on the basis of the determination result (O.K. in the example of  FIG. 32 ) that is included in that Web service use ticket decoding response and creates a document access response including the document (or document contents). Further, the directory service  40  transmits the same to the printing service  100  (sequence SQ 88  of  FIG. 32 ).  
         [0372]     The printing service  100  carries out printing, when the document access response is received, on the basis of the document (or document contents) included in the document access response and creates a printing response including the result of the printing and transmits the same to the client  3  (sequence SQ 89  of  FIG. 32 ).  
         [0373]     As shown in  FIG. 32 , it is also possible to request creation of the Web service use ticket  60  and the service other than the service acquired use the Web service use ticket  60  (or the Web service use ticket ID).  
       EMBODIMENT 4  
       [0374]     Below, an image formation apparatus that forms an image (hereinafter called integrated machine) will be explained by using  FIG. 33  and  FIG. 34  as other examples of the apparatus in which the authentication service  30  and/or the directory service  40  is implemented.  
         [0375]      FIG. 33  is a block diagram showing the functional construction of the integrated machine.  
         [0376]     In  FIG. 33 , the integrated machine  1200  includes a plotter  1201 , a scanner  1202  and a hardware resource  1203  such as facsimile, and further includes a software group  1210  formed of a platform  1220  and an application  1230 , and a integrated machine starter part  1240 .  
         [0377]     The integrated machine starter part  1240  is first executed at the time of power on of the integrated machine  1200  and activates the platform  1220  and the application  1230 .  
         [0378]     The platform  1220  includes: a control service shown below that interprets the processing request from the application  1230  and causes to produce the acquisition request of the hardware resources; a system resource manager (SRM (System Resource Manager)  1223 ) that manages one or plural hardware resources and arbitrates the acquisition requests from the control service  1250 ; and an OS  1221 .  
         [0379]     This control service  1250  is formed from plural service modules. More specifically, there are provided an SCS (System Control Service)  1222 , an ECS (Engine Control Service)  1224 , an MCS (Memory Control Service)  1225 , an OCS (Operation panel Control Service)  1226 , a FCS (fax Control Service)  1227 , an NCS (Network Control Service)  1228 , and an IMH (Imaging Memory Handler)  1229 . It should be noted that this platform  1220  has an application program interface that enables reception of processing request from the above-mentioned applications by a predefined function.  
         [0380]     Here, the OS  1221  is an operating system of UNIX (trade mark), and the like, and carries out each software of the Platform  1220  and the application  1230  as a process by parallel processing.  
         [0381]     The SRM  1223  carries out control of the system and managing of the resource together with SCS 1222 , and achieved arbitration and control of execution according to the requests from the upper layers that use the hardware resources such as engine part that includes scanner, plotter, and the like, memory, HDD files, Host I/Os (Centronix I/F, network I/F, IEEE1394I/F, RS232CI/F, etc.).  
         [0382]     The SCS  1222  carries out plural functions such as application control, operation part control, system screen display (job listing screen, counter display screen etc.), LED display, resource control, interrupt application control, and the like.  
         [0383]     The ECS  1224  controls the engine part such as the plotter  1201 , the scanner  1202 , the hardware resources  1203 , and the like, and carries out image reading, printing, status notification, jam recovery, and the like.  
         [0384]     The MCS  1225  carries out memory control such as acquisition and release of image memory, use of the hard disk apparatus (HDD), compression and decompression of image data, and the like.  
         [0385]     The OCS  1226  is a module that controls an operation panel that functions as information transmission means between the operator and a main control, and carries out processing such as notification of key operation event of the operator to the main control, providing of library functions to each application for construction of GUI, management of constructed GUI information for each of the applications, display to the operation panel, and the like.  
         [0386]     The FCS 1227  provides an API (Application Program Interface) for carrying out facsimile transmission and reception from each application layer of the system controller by using PSTN/ISDN net, registration/quotation of various facsimile data managed by the BKM (backup SRAM), facsimile reading, facsimile reception and printing, and integrated transmission and reception.  
         [0387]     The NCS  1228  is a module group that provides a service commonly to the applications that require a network I/O, and carries out processing such as distribution of the data received from the network side by each protocol to each application, or mediation at the time of transmitting data from the application to the side of network, and the like.  
         [0388]     Furthermore, it is possible to construct such that the NCS  1228  controls the data communications to the network devices connected through the Internet by httpd (Hypertext Transfer Protocol Daemon)  200 , which is one of plural protocols, according to HTTP (Hypertext Transfer Protocol), activate the processing part corresponding to the Web service designated by the HTTP request header by function call, and notify the processing result by the Web service to the network device with an HTTP response. For example, the Web service is provided in accordance with the message described by XML (extensible Markup Language).  
         [0389]     The IMH  1229  maps the image data to the physical memory from the virtual memory region (user virtual space). Upon activation of the process, it carries out the system call and maps the virtual memory region for the process or releases the virtual memory region thus mapped at the end of the process.  
         [0390]     The application  1230  includes a printer application  1211 , which is the application for a printer and including page description language (PDL), PCL and also postscript (PS), a copy application  1212 , which is an application for copying, a facsimile application  1213 , which is an application for facsimile, a scanner application  1214 , which is an application for scanner, and a Web service processing application  1215 , which is a Web service application. Also, it is possible to install a new application via the network connected by the NCS  1228 . Also, each of the applications can be added or deleted individually.  
         [0391]     The Web service processing application  1215  includes a Web server  500  that receives the HTTP request requesting a Web service and provide the Web service by transmitting an HTTP response, and a Web service function (WSF)  1400 , wherein the WSF  1400  carries out a predetermined processing by utilizing the control service  1250  through API (Application Program Interface) and provides the processing result through the WS-API (Web Service Application Program Interface) as the Web service.  
         [0392]     In the present embodiment, the authentication service  30  and/or directory service  40  are implemented to the Web service function  1400 .  
         [0393]     Also, the authentication ticket  50 , the user information, the group information, the Web service use ticket  60  and/or the session  70 , and the like, are held in the HDD  1303  to be described later.  
         [0394]      FIG. 34  is a block diagram showing the hardware construction of an integrated machine  1200 .  
         [0395]     As shown in  FIG. 34 , the integrated machine  1200  has a construction in which an operation panel  1310 , a fax control unit (FCU)  1530 , an engine part  1350  (the scanner  1202 , or the like, is connected), and an ASIC  1301  of the plotter  1201  and the controller  1300  are connected by a PCI (Peripheral Component Interconnect) bus  1309 , and the like.  
         [0396]     The controller  1300  connects the MEM-C  1302 , the HDD (Hard Disk Drive)  1303 , and the like, to the ASIC 1301  and further connects this ASIC  1301  to a CPU  1304  via an NB  1305 , which is a CPU chip set.  
         [0397]     Here, it should be noted that the ASIC  1301  and the NB  1305  are connected not via the PCI but via an AGP  1308 .  
         [0398]     The CPU 1304  carries out overall control of the integrated machine  1200 . More specifically, it activates the SCS  1222 , the SRM  1223 , the ECS  1224 , the MCS  1225 , the OCS  1226 , the FCS 1227 , and the NCS  1228  that form a platform  1220  on the OS  1221  as a process and causes them to execute the respective processes. Further, it activates the printer application  1211 , the copy application  1212 , the fax application  1213 , the scanner application  1214 , and the Web service processing application  1215 , which constitute the application  1230  as the process and causes them to execute the respective processes.  
         [0399]     The NB  1305  is a bridge for connecting the CPU  1304  to an MEMP  1306 , an SB  1307 , an NIC (Network Interface Card)  1341 , a USB (Universal Serial Bus)  1330 , an IEEE1394  1340 , a Centronix  1342 , a driver I/F  1343 , and ASIC  1301 .  
         [0400]     Here, it should be noted that MEMP 1306  is a system memory used as an image memory of an integrated machine, while the SB  1307  is a bridge that connects the NB  1305  to the ROMPCI device and the peripheral device. It should be noted that the MEM-C 1302  is a local memory used for a copy image buffer and code buffer while ASIC  1301  is an IC for image processing application that has a hardware element for image processing.  
         [0401]     The driver I/F 1343  is an I/F (interface) used for reading the program or application from an inserted recording medium that stores the program or application and install the same to the integrated machine  1200 . Here, the recording medium includes SD memory card, smart media, multimedia card, CompactFlash (trade mark), and the like.  
         [0402]     The HDD  1303  is a storage that accumulates image data, programs, font data, forms, and documents. Further, the HDD  1303  holds the authentication ticket  50 , user information, group information, Web service use ticket  60 , and/or the session  70 , and the like, of the present embodiment.  
         [0403]     Here, it should be noted that the operational panel  1310  is an operation part for accepting input operation of the operator and for providing display to the operator.  
         [0404]     The ASIC  1301  is provided with a RAM interface for connecting the MEM-C 1302  and further a hard disk interface for connecting the HDD 1303 . In the case of conducting input or output of image data to and from these memory parts, the source of input or destination of output is switched to the RAM interface or the hard disk interface.  
         [0405]     The AGP  1308  is a bus interface of graphics accelerator card proposed for speeding up the graphic processing. Thus, the AGP  1308  speeds up the graphics accelerator card by accessing to the system memory directly with high throughput.  
         [0406]     Further, the present invention is by no means limited to the embodiments described heretofore, but various variations and modifications may be made without departing from the scope of the invention.  
         [0407]     The present invention is based on the Japanese Priority Patent Applications No.2003-162592 and No.2003-162593 both filed on Jun. 6, 2003 and Japanese Priority Patent Applications No.2004-162239 and 2004-162240 both filed on May 31, 2004, the entire contents of which are incorporated herein as reference.