User approval system and user approval method

Abstract

To provide a user approval system and a user approval method configured so that a data providing unit grasps information on components which are intermediates to a destination and determines whether to permit an access to data.SOLUTION: A user approval system includes: an authentication unit 70 which manage authentication information, attribute information and issued qualification information of a plurality of entities including a supplier and a receiver of data which is provided in accordance with a request and relay components; and an STS (Security Token Service ) 30 which serves as a qualification information generation unit configured to generate qualification information including a commission item based on qualification information of one entity and qualification of another entity, and provide the qualification information to a specific entity out of the multiple entities, in accordance with a request. The STS provides information on the other entities through which the request passes, to the specific entity from which the qualification information has been received, based on the qualification information generated by the STS.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present invention relates to a user authorization system and a user authorization method, and is suitably applied to a user authorization system relating to an authentication and authorization method for accessing protected data and resources, for example. [Background technology]

[0002] In a standard authentication and authorization framework such as OpenID Connect, when accessing a protected resource, the requester (person or device) obtains an authentication result from an authentication component using its own credentials, and then sends an access request to the protected resource to the server using the obtained authentication result.

[0003] The server is the point where the authorization result is enforced, and queries the authorization component as to whether authorization is allowed or not. The authorization component queries the authentication component as to the validity of the authentication result, and if it receives information from the authentication component indicating that the authentication result is valid, it returns to the server whether the access request is allowed or not based on the policy.

[0004] The server processes the access request to the protected resource etc. based on the result of authorization obtained from the authorization component (see Non-Patent Document 1). When judging whether to authorize the access request, the authentication component performs judgment processing based on a predetermined policy. One of the policies is ABAC (Attribute Based Access Control), which means access control based on attributes. This access control judges whether to authorize based on attributes such as the affiliation, job title, and location of the requester.

[0005] When authorizing an access request using the attributes of the requester, the correctness of the attributes must be guaranteed. However, since it would be a heavy load for the authentication component to perform this task, the authentication component must cooperate with another component, for example, an attribute authority.

[0006] Also disclosed is a method for managing a server's access to a target service on behalf of a client using a delegation framework. For example, a method is disclosed in which a trusted third party determines whether the server is authorized to access a target service on behalf of a client when issuing credentials to the server, and issues the credentials based on the result of this determination (see Patent Document 1).

[0007] In recent years, data integration across organizations and fields has been implemented around the world. Data integration across organizations and fields poses various challenges, such as data discovery, authentication and authorization, and differences in protocols when exchanging data. To solve these problems, a data integration platform is constructed, and users communicate with each other through components called connectors, or use services that support data integration. This approach is adopted in CADDE (Connector Architecture for Decentralized Data Exchange) and IDS (International Data Spaces). CADDE is a connector architecture for decentralized data exchange, and IDS is an architecture considered as a realization form of the data integration initiative GAIA-X, which is being constructed mainly in Europe.

[0008] Specifically, when a user (hereinafter also referred to as a data user) who wants to acquire data acquires data, the user issues a data acquisition request to a connector (hereinafter also referred to as a provider connector) to a data integration platform used by a user (hereinafter also referred to as a data provider) who provides the data, via a connector (hereinafter also referred to as a user connector) to a data integration platform used by the user (hereinafter also referred to as a data provider). The provider connector interprets the data acquisition request, accesses protected data managed by the data provider as necessary, and passes the data obtained by the access to the user connector.

[0009] In addition, the user connector or provider connector in the data integration platform is equipped with a webAPI (Application Programming Interface) because it is assumed that the connector will be used not only directly by the data user or data provider but also by some kind of program. Therefore, when exchanging data using the data integration platform, a data acquisition request from a data user is made via multiple components, including the data user, program, user connector, and provider connector.

[0010] In recent years, interest in data management has been growing due to the increased focus on data utilization. Data is intangible and therefore not subject to ownership, but the idea of ​​data ownership or data sovereignty, which means that those who contribute to the generation of data can decide how to handle the data, is becoming mainstream.

[0011] Therefore, in the data integration platforms adopted by the aforementioned CADDE and IDS, data is stored in a decentralized manner, and authorization for access to data is also distributed to the provider connector itself and to the services used by each provider connector. [Prior art documents] [Patent documents]

[0012] [Patent Document 1] JP 2003-99401 A [Non-patent literature]

[0013] [Non-Patent Document 1] OpenID Connect Core 1.0 incorporating errata set 1\footnote {\url{http: / / openid-foundation-japan.github.io / openid-connect-core-1_0.ja.html}} Summary of the Invention [Problem to be solved by the invention]

[0014] As mentioned above, when data is acquired using a data integration platform, data is exchanged via multiple components. At this time, there may be a need to restrict elements such as components on the path. For example, when a path is constructed in the order of data user, program, user connector, and provider connector, if the program can be used by other data users not authorized by the data provider and is configured to cache data during processing, if the program behaves inappropriately or is managed in an inappropriate state, other data users not authorized by the data provider may be able to acquire data provided by the data provider.

[0015] Moreover, in this case, the data provider can know that the user connector and the data user are involved, but cannot know the existence of the program. To prevent such a situation, the data provider may wish to restrict not only the data user who ultimately acquires the data, but also the route by which the data was acquired.

[0016] In this case, it is possible to adopt the method described in Patent Document 1, but in this method, authorization for requests and issuance of credential information must be performed by the same component. Therefore, when this method is used in a data integration platform, a data provider who wants to perform authorization for requests by himself / herself must also issue credential information and perform related processes by himself / herself, which poses a problem that the burden at the time of implementation increases when building a system using a data integration platform.

[0017] The present invention has been made in consideration of the above points, and aims to propose a user authorization system and a user authorization method that enable a data provider to grasp information regarding the components that the data passes through on its way to its destination, and to use the information regarding the components to determine whether or not to allow access to the data. [Means for solving the problem]

[0018] In order to solve such problems, the present invention comprises an authentication unit that manages authentication information, attribute information and issued credential information regarding multiple entities involved in the exchange of requests, such as sources and destinations of data that may be provided in response to a request, and relay components through which the request may pass, and a credential information generation unit that generates credential information including delegation terms based on the credential information of one of the multiple entities and the credential information of the other entities, and provides this to a specific entity of the multiple entities in response to the request, and the credential information generation unit provides information regarding the other entities through which the request may pass, to the specific entity that received the credential information, based on the credential information generated by the credential information generation unit.

[0019] In addition, the present invention includes an authentication step in which an authentication unit of a user authorization system manages authentication information, attribute information and issued credential information regarding multiple entities involved in the exchange of a request, such as the source and destination of data that may be provided in response to a request, and relay components through which the request may pass, and a credential information generation step in which a credential information generation unit of the user authorization system generates credential information including a delegation term based on the credential information of one entity among the multiple entities and the credential information of the other entities, and provides the credential information to a specific entity among the multiple entities in response to the request, wherein in the credential information generation step, the credential information generation unit provides information regarding the other entities through which the request may pass, to the specific entity that received the credential information, based on the credential information generated by the credential information generation unit. Effect of the Invention

[0020] According to the present invention, the data provider can obtain information about components via which data is passed, and can use the components to determine whether access is permitted or not. [Brief description of the drawings]

[0021] [Figure 1] 1 is a block diagram showing an example of a logical configuration of a user authorization system according to a first embodiment. [Diagram 2] FIG. 4 is a diagram showing an example of the configuration of authentication information according to the first embodiment; [Diagram 3] FIG. 4 is a diagram showing an example of the configuration of attribute information according to the first embodiment. [Figure 4] FIG. 4 is a diagram showing an example of the configuration of qualification information according to the first embodiment; [Diagram 5] FIG. 2 is a diagram illustrating an example of the configuration of ID mapping according to the first embodiment. [Figure 6] FIG. 4 is a diagram showing an example of the configuration of qualification information according to the first embodiment; [Figure 7] FIG. 11 is a diagram showing another example of the configuration of qualification information according to the first embodiment. [Figure 8] FIG. 2 is a sequence diagram showing an example of a user authorization method in the user authorization system according to the first embodiment. [Figure 9] FIG. 2 is an activity diagram for explaining an STS update process according to the first embodiment. [Figure 10] FIG. 11 is a block diagram showing an example of a logical configuration of a user authorization system according to a second embodiment. [Figure 11] FIG. 11 is a configuration diagram showing an example of attribute mapping according to the second embodiment. [Figure 12] FIG. 11 is a configuration diagram illustrating an example of an authorization policy according to the second embodiment. [Figure 13] FIG. 11 is a sequence diagram showing an example of a user authorization method in the user authorization system according to the second embodiment. [Figure 14] FIG. 13 is a block diagram showing an example of a logical configuration of a user authorization system according to a third embodiment. [Figure 15] FIG. 13 is a diagram illustrating an example of the configuration of a qualification information history according to the third embodiment. [Figure 16] FIG. 13 is a diagram illustrating an example of the configuration of qualification information according to the third embodiment. [Figure 17] FIG. 13 is a sequence diagram showing an example of a user authorization method in the user authorization system according to the third embodiment. [Figure 18] FIG. 11 is a sequence diagram showing an example of a user authorization method in a user authorization system according to a first modified example. [Figure 19] FIG. 11 is a sequence diagram showing an example of a user authorization method in a user authorization system according to a second modified example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0023] (1) First embodiment 1 is a block diagram showing an example of a logical configuration of a user authorization system 1 according to a first embodiment. In the illustrated example, the user authorization system 1 includes authentication units 10 and 20, and an STS (Security Token Service) 30. Elements related to the present invention include a request transmission component 40, at least one relay (via) component 51, . . . , 5N, and a request reception component 60. In the following description, when there is no particular need to mention multiple relay components, the relay component 51 will be given as an example.

[0024] This user authorization system 1 provides functions to a plurality of components including a source and destination of data that may be provided in response to a request, and a relay component through which the request may pass. In the following explanation, each component, program, etc. is also referred to as an "entity." In each drawing, the request sending component is abbreviated to "request sending," the relay component to "relay," the request receiving component to "request receiving," and the authentication component to "authentication."

[0025] The user authorization system 1 is configured by at least one computer having, as hardware, for example, a processor, a main storage device, an auxiliary storage device, an input device, an output device, and a communication device. The main storage device is a device for storing computer programs and data, such as a ROM (Read Only Memory), a RAM (Random Access Memory), and a non-volatile semiconductor memory. The auxiliary storage device is, for example, a hard disk drive, an SSD (Solid State Drive), an optical storage medium (for example, a CD (Compact Disc) and a DVD (Digital Versatile Disc)), a storage system, an IC card (Integrated Circuit Card), an SD (Secure Digital) memory card, and a storage area of ​​a cloud server. The computer programs and data stored in the auxiliary storage device are read into the main storage device as needed.

[0026] The input device is, for example, a keyboard, a mouse, a touch panel, a card reader, a voice input device, etc. The output device (display device) is a user interface that provides the user with various information such as the progress and results of processing. The output device is, for example, a screen display device (i.e., a liquid crystal monitor, LCD (Liquid Crystal Display), or a graphic card), a voice output device (i.e., a speaker, etc.), or a printer, etc. The communication device is a wired or wireless communication interface that realizes communication with other devices via a communication means such as a LAN or the Internet. The communication device is, for example, a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Bus) module, or a serial communication module, etc.

[0027] The authentication unit 10, for example, manages information relating to the authentication of a person (user). The authentication unit 10 is an authentication program having an information transmission and reception function, and includes authentication information 11, attribute information 12, and qualification information 13. The authentication information 11, attribute information 12, and qualification information 13 will be described in detail later. The authentication unit 20 manages information relating to the authentication of a device. The authentication unit 20 is an authentication program having an information transmission and reception function, and includes authentication information 21, attribute information 22, and qualification information 23. The authentication information 21, attribute information 22, and qualification information 23 will be described in detail later. The STS 30, for example, executes processes related to qualification information and processes for transmitting and receiving data, and includes ID (Identification) mapping 31 and qualification information 32. The ID mapping 31 and qualification information 32 will be described in detail later.

[0028] The STS 30 is a type of Web service that issues, verifies, and updates security tokens. The STS 30 is an example of a credential information generating unit, and generates credential information including a delegation term, which will be described later, based on the credential information of one component among the multiple components and the credential information of another component among the multiple components, and provides the credential information to a specific entity among the multiple entities upon request. Based on the credential information generated by the STS 30, the STS 30 provides information about other entities through which the above-mentioned request is made to the specific entity that received the credential information. Here, the STS 30 provides the credential information, including information about other entities through which the above-mentioned request is made, to the specific entity.

[0029] The request transmission component 40 is, for example, a request transmission program that transmits a data acquisition request (access request) according to a request from a data user to a communication target (for example, the relay component 51) and transmits and receives data to and from the communication target. The relay components 51 to 5N are, for example, relay programs that relay data from a communication target (for example, the request transmission component 40). The request reception component 60 is, for example, a request reception program that is installed in a computer (server) managed by a data provider, controls access to data stored in a storage device of the computer, and transmits and receives data to and from the communication target (for example, the relay component 51).

[0030] FIG. 2 is a diagram showing a configuration example of authentication information according to the first embodiment. In the illustrated example, the authentication information 11 is information in a table format, and has an ID 11a, a type 11b, and a value (authentication information) 11c. The ID 11a indicates an identifier that uniquely identifies a person (user), and is, for example, information "xx". The type 11b indicates the type of the authentication information 11, and is, for example, information "password". The value 11c indicates the value of the authentication information 11, and is, for example, information "password". Note that the authentication information 21 is information in a table format, similar to the authentication information 11, and has an ID, a type, and a value, which are not shown. In this case, the ID of the authentication information 21 indicates an identifier that uniquely identifies a device, and is, for example, information "xx". The values ​​11c and 21c of the authentication information 11 and 21 indicate values ​​that can be used as authentication information, such as a password stored in a plain text state or in an encoded state, public key information stored, or other values.

[0031] FIG. 3 is a diagram showing a configuration example of attribute information according to the first embodiment. In the illustrated example, the attribute information 12 is information in a table format, and has an ID 12a, an attribute key 12b, and an attribute value 12c. The ID 12a indicates an identifier that uniquely identifies a person (user), and is, for example, information "xx". The attribute key 12b indicates key information that indicates an attribute of the attribute information 12, and is, for example, information "type". The attribute value 12c indicates a value of an attribute of the attribute information 12, and is, for example, information "person". The attribute information 22 is information in a table format, similar to the attribute information 12, and has an ID, an attribute key, and an attribute value, which are not shown. In this case, the ID 22a of the attribute information 22 indicates an identifier that uniquely identifies a device, and is, for example, information "yy".

[0032] FIG. 4 is a diagram showing a configuration example of the qualification information according to the first embodiment. In the illustrated example, the qualification information 13 is information in a table format, and has a qualification information ID 13a and an expiration date 13b. The qualification information ID 13a indicates an identifier that uniquely identifies the qualification information issued by the authentication unit 10, and is, for example, a character string included in a qualification information ID claim in the qualification information. The expiration date 13b indicates the expiration date of the qualification information 13, and is, for example, date and time information. The qualification information 23 is information in a table format like the qualification information 13, and has a qualification information ID and an expiration date, not shown. The qualification information 32 is information in a table format like the qualification information 13, and has a qualification information ID and an expiration date, not shown. The qualification information ID of the qualification information 23 indicates a character string that uniquely identifies the qualification information issued by the authentication unit 20. In addition, the qualification information ID 32a of the qualification information 32 stores an identifier that uniquely identifies the qualification information 32 issued by the STS 30.

[0033] Fig. 5 is a diagram showing a configuration example of ID mapping according to the first embodiment. In the illustrated example, ID mapping 31 is information in a table format, and has ID (IDentifier) ​​31a, issuer 31b, and ID on issuer 31c. In the following description, issuer is also referred to as "issuer". ID 31a indicates an identifier that uniquely identifies a person or device managed by STS 30. Issuer 31b is information for specifying authentication unit 10 or authentication unit 20 that can be an issuer of authentication information, and is indicated by using, for example, a Uniform Resource Identifier (URI). ID on issuer 31c indicates an identifier for identifying the issuer indicated by issuer 31b.

[0034] FIG. 6 is a diagram showing a configuration example of the credentials according to the first embodiment. In the illustrated example, the credentials 100 is information issued as a token by the authentication unit 10 and the authentication unit 20, and has a format 101, a payload 102, and a signature 103. Information on the format of the credentials 100 is recorded in the format 101. The payload 102 includes a credentials ID 111 that uniquely identifies the credentials 100, an issuer URI 112 that indicates the URI of the issuer that issues the credentials 100, a target ID 113 that uniquely identifies the target of the credentials 100, and attributes (attribute 1, attribute 2, . . .) 114 of the credentials 100. The signature 103 records the signature of the issuer of the credentials 100. A component that receives the credentials 100 can check the format by referring to the format 101, and can check whether it has been tampered with on the way.

[0035] 7 is a diagram showing another example of the configuration of credentials according to the first embodiment. In the illustrated example, the credentials 200 is information issued by the STS 30 as a token including delegation information, and has a format 201, a payload 202, and a signature 203. The format 201 includes information on the format of the credentials 200. The payload 202 includes a credentials ID 211 that uniquely identifies the credentials 200, an issuer URI 212 that indicates the URI of the issuer (here, the STS 30 is illustrated) that issues the credentials 200, a target ID 213 that uniquely identifies the target of the credentials 200, attributes (attribute 1, attribute 2, ...) 214 of the credentials 200, and acts 215 that is a key of the delegation assertion including the ID of the delegator of the delegation assertion and the ID of the delegation recipient. The signature 203 indicates the signature of the issuer of the credentials 200.

[0036] 8 is a sequence diagram showing an example of a user authorization method in the user authorization system 1 according to the first embodiment. The illustrated example is a sequence diagram showing a flow from when the request transmission component 40 issues a request to the request reception component 60 until the request arrives via the relay component 51.

[0037] First, an overview of the user authorization method of the user authorization system 1 of this embodiment will be given. The user authorization method includes an authentication step in which the authentication unit 70 of the user authorization system 1 manages authentication information, attribute information, and issued credential information related to multiple entities involved in the exchange of requests, such as the source and destination of data that may be provided in response to a request, and relay components through which the request may pass, and authenticates the multiple entities, and a credential information generation step in which the STS 30 generates credential information including delegation terms based on the credential information of one of the multiple entities and the credential information of another of the multiple entities, and provides the credential information to a specific entity of the multiple entities in response to the request. In the credential information generation step, the STS 30 provides information related to the other entities through which the request may pass, to the specific entity that received the credential information, based on the credential information generated by the authentication unit 70 or STS 30.

[0038] First, the request transmission component 40 requests a subject that can be authenticated by the authentication unit 10 or the authentication unit 20 to obtain credentials information, and obtains the credentials information (step F01). In the illustrated example, the subject is the authentication unit 70. This authentication unit 70 has authentication information, attribute information, and issued credentials information of multiple entities, and authenticates multiple entities. The above-mentioned process flow is performed, for example, by the Authorization code flow or Client credentials flow defined by OpenID Connect.

[0039] The request transmission component 40 sends a request to the request receiving component 60 to the relay component 51 (step F02). At this time, the request transmission component 40 sends, as parameters of the request, the credential information acquired in step F01, an identifier of the request receiving component 60 such as a URL (Uniform Resource Locator), and information such as the URL of the resource to be acquired.

[0040] The relay component 51 requests a subject that can authenticate itself, such as the authentication unit 10 or the authentication unit 20 (the authentication unit 70 in the illustrated example), to acquire the qualification information, and acquires the qualification information (step F03).

[0041] The relay component 51 sends a request to update the qualification information that the request transmission component 40 has assigned as a parameter of the request to the STS 30 (step F04). At this time, the relay component 51 also assigns its own qualification information acquired by itself as a parameter.

[0042] The STS 30 determines the validity of the credentials of the relay component 51 sent in step F04, for the authentication unit 70 that issued the credentials. Furthermore, the STS 30 determines the validity of the credentials for which the relay component 51 has requested to update, for the authentication unit 70 that issued the credentials (step F05). This is performed, for example, using a method such as token introspection defined by OpenID Connect.

[0043] If the STS 30 confirms the validity of the credentials of both the sending and receiving sides in step F05, the STS 30 updates the credentials for which an update request was issued (step F06). At this time, the STS 30 issues credentials to the relay component 51, and includes in the credentials information information that the relay component 51 is making a request on behalf of the request sending component 40. Hereinafter, such information that a request is being made on behalf of the request sending component 40 is also referred to as a "delegation term."

[0044] In step F06, the STS 30 returns the qualification information that the STS 30 created as a response to the request from the relay component 51 in step F04 (step F07).

[0045] The relay component 51 sends a request to the request receiving component 60 based on the request received from the request sending component 40 (step F08). At this time, the relay component 51 sends parameters including the qualification information obtained in step F07 and the URI of the resource to be acquired that was sent in step F01.

[0046] The request receiving component 60 determines the validity of the credentials sent in step F08 with respect to the STS 30 (F09).

[0047] After the validity is verified, the request receiving component 60 checks the delegation terms included in the credentials (step F10). Note that this operation does not have to be performed if the request receiving component 60 does not require it.

[0048] The request receiving component 60 returns a response to the request in step F08 (step F11). The relay component 51 returns a response to the request in step F02 (step F12).

[0049] Fig. 9 is an activity diagram for explaining the credential information update process by the STS 30 according to the first embodiment. In the illustrated example, when the STS 30 executes the credential information update process in step F06 shown in Fig. 8, it executes a process G1 for acquiring information to be assigned to the delegation term and a process G2 for creating the credential information to which the delegation term is assigned.

[0050] The STS 30 executes the following process in process G1. That is, first, in process G01, the STS 30 obtains information on the delegatee (relay component 51) using the credential information of the requester (relay component 51) of the credential information update request. At this time, the STS 30 refers to the ID mapping 31 based on the IDs of the issuer of the credential information and the credential information issuer, and resolves the ID in the STS 30. Note that if the STS 30 is the issuer of the credential information, it uses the ID as is.

[0051] Next, the STS 30 obtains information about the delegation source (request transmission component 40) using the credential information requested to be updated by the requester of the credential information update request (relay component 51) (i.e., the credential information to be updated). In this case, if the STS 30 is the issuer of the credential information, the STS 30 uses the ID as is.

[0052] Next, the STS 30 executes the following process in process G2: In process G03, the STS 30 checks whether or not there is a delegation assertion in the credential information (the credential information 100 to be updated) requested to be updated by the requester of the credential information update request (the relay component 51), and creates a list of delegation assertions if there is a delegation assertion, whereas it creates an empty list if there is no delegation assertion.

[0053] Next, STS30 adds a delegation term to the list of delegation claims created in process G03 or an empty list, using information about the delegator obtained in process G01 and information about the delegator obtained in process G02, and creates qualification information 200 with the delegation term attached (process G04).

[0054] As described above, the user authorization system 1 of this embodiment comprises an authentication unit 70 that manages authentication information, attribute information, and issued credential information regarding multiple entities involved in the exchange of requests, such as the source and destination of data that may be provided in response to a request, and relay components through which the request may pass, and authenticates the multiple entities, and an STS 30 that generates credential information including delegation terms based on the credential information of one of the multiple entities and the credential information of another of the multiple entities, and provides this to a specific entity of the multiple entities in response to a request, and the STS 30 provides information regarding the other entities through which the above-mentioned request passes, to the specific entity that received the credential information, based on the credential information generated by STS 30.

[0055] In this way, the data providing unit can grasp information about components that are passed through on the way to the data destination, and can use the information about the components to determine whether or not to allow access to the data. In this configuration, it is possible to separate a part that handles information about components that are passed through from a part that performs processing such as authorization using the information about components that are passed through.

[0056] In the user authorization system according to the present embodiment, the STS 30 provides the specific entity with information about other entities through which the request passes, including the information in the qualification information. In this way, the data providing unit can use the information about other entities included in the qualification information to grasp information about components through which the request passes on the way to the data destination, and can use the information about the components to determine whether or not to permit access to the data.

[0057] (2) Second embodiment Since the user authorization system and user authorization method according to the second embodiment have almost the same configuration and operation as the user authorization system and user authorization method according to the first embodiment described above, the same configuration and operation will not be described again, and the following description will focus on the differences.

[0058] In the user authorization system of the second embodiment, an attribute mapping 33 is added to the STS 30 of the first embodiment, and an authorization unit 80 is added, for example, to a computer on which a request receiving component 60 is installed, but the other configurations are the same as those of the user authorization system 1 of the first embodiment.

[0059] 10 is a block diagram showing an example of a logical configuration of a user authorization system according to the second embodiment. In the illustrated example, the user authorization system 1 includes authentication units 10 and 20, an STS 30, a request transmission component 40, a plurality of relay components 51 to 5N, a request reception component 60, and an authorization unit 80. In this embodiment, the authorization unit is abbreviated to "authorization" in the drawings.

[0060] The STS 30 includes an attribute mapping 33 for converting attributes belonging to the credentials 100 into attributes belonging to the credentials 200. The authorization unit 80 includes an authorization policy 81. The authorization unit 80 performs authorization processing for the credentials 200 based on information recorded in the authorization policy 81.

[0061] 11 is a diagram showing an example of attribute mapping 33 according to the second embodiment. In the illustrated example, the attribute mapping 33 is information in a table format, and has an attribute name 33a, an issuer 33b, and an attribute name on the issuer 33c. In this embodiment, for example, the delegation source and the delegation destination between the authentication unit 70 and the STS 30 do not always match, so the attribute mapping 33 is provided to manage the correspondence between them.

[0062] The attribute name 33a indicates a name (value) indicating the type of attribute belonging to the qualification information 200 issued by the STS 30. The issuer 33b indicates an identifier of the authentication unit 10 that authenticates a person (user) or an identifier of the authentication unit 20 that authenticates a device, and is described by, for example, a URI that indicates the authentication unit 10 or the authentication unit 20.

[0063] The attribute name on the issuer 33c stores a value indicating which attribute name on the corresponding issuer this attribute corresponds to. That is, the STS 30 can convert an attribute belonging to the qualification information 100 into an attribute belonging to the qualification information 200 by referring to the attribute mapping 33.

[0064] 12 is a configuration diagram showing an example of an authorization policy 81 according to the second embodiment. In the illustrated example, the authorization policy 81 is information in a table format, and has an external public resource URI 81a, an authorization condition 81b, and an authorization type 81c.

[0065] The external public resource URI 81a is a resource that is made public to the outside. The external public resource URI 81a is information (value) for identifying the contents of a request when, for example, the request transmission component 40 transmits a request (data acquisition request) to the request reception component 60, and indicates the URI of the requested data, etc.

[0066] The authorization condition 81b is information indicating the authorization condition, and is information expressed as a combination of conditions and logical operations "and / or" using, for example, the format of XML (Extensible Markup Language). In the illustrated example, the authorization condition 81b indicates a condition that the delegator and the delegate are from the same organization, and the location of the delegate is Japan.

[0067] The authorization type 81c is information (value) on whether authorization is possible or not, and is information of “permitted” or “rejected.” For example, when the contents of the data acquisition request match the information recorded in the authorization conditions 81b, the authorization type 81c is information of “permitted,” whereas when the contents of the data acquisition request do not match the information recorded in the authorization conditions 81b, the authorization type 81c is information of “rejected.”

[0068] Fig. 13 is a sequence diagram showing an example of a user authorization method in the user authorization system according to the second embodiment. In Fig. 13, steps M01 to M05 are similar to steps F01 to F05 in Fig. 8 according to the first embodiment, and therefore description thereof will be omitted.

[0069] In step M06, when the STS 30 updates the qualification information 100 and issues the qualification information 200, if the contents of the attribute 114 belonging to the qualification information 100 differ from the contents of the attribute 214 belonging to the qualification information 200, the STS 30 refers to the attribute mapping 33 and converts the attribute (attribute name) belonging to the qualification information 100 into the attribute (attribute name) belonging to the qualification information 200. Steps M07 to M09 are similar to steps F07 to F09 in Fig. 8 according to the first embodiment, and therefore description thereof will be omitted.

[0070] Next, in step M10, when the request receiving component 60 checks the validity of the credential information 200 in step M09, if the credential information 200 does not contain the attribute information required to determine whether or not to authorize the data acquisition request, the request receiving component 60 sends an attribute information acquisition request to the STS 30 to request attribute information of the target ID.

[0071] In step M11, when the STS 30 receives a request to obtain attribute information from the request receiving component 60, it refers to the ID mapping 31, and based on the information recorded in the ID mapping 31, identifies the authentication unit 70 that authenticated the target ID, requests attribute information from the identified authentication unit 70, and obtains the attribute information from the authentication unit 70.

[0072] In step M12, when the STS 30 acquires the attribute information from the authentication unit 70, the STS 30 transmits this attribute information to the request receiving component 60 as a response (return value) to the attribute information acquisition request in step M10.

[0073] When the request receiving component 60 receives the necessary attribute information from the STS 30, it acquires the authorization policy 81 from the authorization unit 80 based on a value (information) for identifying the request content included in the data acquisition request, and judges whether to authorize the data acquisition request based on the acquired authorization policy 81 (step M13). That is, the request receiving component 60 judges whether the request content included in the data acquisition request matches the information recorded in the authorization condition 81b of the authorization policy 81.

[0074] In step M14, if the request content matches the permission conditions of the authorization policy 81 and the authorization decision result is "permitted," the request receiving component 60 returns data to the relay component 51 as a return value of the data acquisition request in step M08. That is, the request receiving component 60 accesses the data storage device based on the URI (data access destination) added to the data acquisition request, reads the data requested in the data acquisition request from the data storage device, and transmits the read data to the relay component 51 as a response to the data acquisition request.

[0075] In step M15, the relay component 51 transmits the data received from the request receiving component 60 to the request transmitting component 40 as a response to the data acquisition request received in step M02. This allows the request transmitting component 40 to acquire the data in response to the data acquisition request.

[0076] The user authorization system according to this embodiment includes an authorization unit 80 that determines whether or not to permit access to a data provider based on the qualification information generated by the STS 30 and on an authorization policy 81. In this way, it is possible to strictly determine whether or not to permit access to a data provider based on the contents of the authorization policy 81.

[0077] (3) Third embodiment Since the user authorization system and user authorization method according to the third embodiment have almost the same configuration and operation as the user authorization system and user authorization method according to the second embodiment described above, the same configuration and operation will not be described again, and the following description will focus on the differences.

[0078] 14 is a diagram showing an example of a logical configuration of a user authorization system according to the third embodiment. In the user authorization system according to the third embodiment, a credential information history 34, which is a database for recording a history of credential information, is added to the STS 30 of the user authorization system according to the second embodiment, and the authorization unit 80 is omitted, but the other configurations are the same as those of the user authorization system according to the second embodiment. The credential information history 34 will be described later.

[0079] 15 is a diagram showing an example of the configuration of the credential information history 34 according to the third embodiment. In the illustrated example, the credential information history 34 is information in a table format, and manages a case ID 34a, a sender ID 34b, and a time 34c. The case ID 34a is an identifier assigned by the STS 30 to track a series of relay components 51, etc. The sender ID 34b is an ID (identifier) ​​for identifying other entities involved in the request and the route. The time 34c is the time when the STS 30 made a credential information recording request.

[0080] In this embodiment, the STS 30 holds information about other entities through which a request is made in the credential information history 34, and when the STS 30 receives a route record request from a specific entity, the STS 30 provides the specific entity with an ID for identifying the other entity indicated by the sender ID 34b as information about the other entity. The specific entity uses the ID for identifying the other entity to grasp the other entities through which the request is made.

[0081] Fig. 16 is a diagram showing an example of the configuration of qualification information 300 according to the third embodiment. In Fig. 16, qualification information 300 is information including route tracing information as information related to a route. Qualification information 300 has a format 301, a payload 302, and a signature 303. Format 301 indicates the format of qualification information 300. Payload 302 indicates the data body. Payload 302 will be described later. Signature 303 indicates the signature of the issuer of qualification information 300.

[0082] The above-mentioned payload 302 includes a credential ID 311 that uniquely identifies the credential 300, an issuer URI 312 that indicates the URI of the issuer that issues the credential 300, a subject ID 313 that uniquely identifies the subject of the credential 300, attributes (attribute 1, attribute 2, ...) 314 of the credential 300, and a caseID 315. The caseID 315 corresponds to the above-mentioned caseID 34a (see Fig. 15), and indicates a value corresponding to the key called caseID315.

[0083] 17 is a sequence diagram showing an example of a user authorization method in the user authorization system according to the third embodiment. In this user authorization method, the token itself is used instead of a caseID. In the illustrated example, the processes in steps S01 to S03 are similar to the processes in steps F01 to F03 in the first embodiment.

[0084] In step S04, after the relay component 51 acquires the credential information using the authentication information in step S03, it transmits to the STS 30 a route record request including the credential information of the relay component 51 acquired in step S03 and the credential information 13 added to the data acquisition request received in step S02.

[0085] In step S05, when the STS 30 receives a route record request from the relay component 51, the STS 30 transmits and receives information to and from the authentication unit 70 that issued the respective credentials in order to confirm the validity of the credentials 13 and the credentials of the relay component 51.

[0086] In step S05, if both STS 30 and authentication unit 70 are able to confirm the validity of the credentials 13 and the credentials of relay component 51, STS 30 calculates a hash value of each credential information instead of the case ID in order to link the history of the series of routes, and records the identifier of the component that issued the route record request (in this case, relay component 51) and the time (the time the route record request was received) and the hash value of each credential information in the credentials history 34 (step S06).

[0087] In step S07, when the STS 30 completes the route record process, it transmits information indicating that the route record process has been completed to the relay component 51 as a response to the route record request.

[0088] In step S08, when the relay component 51 receives information that the route record processing has been completed, it sends a data acquisition request to the request receiving component 60, the data acquisition request including information such as the URI of the resource to be acquired received in step S02 and the credential information (the credential information 13 added to the data acquisition request in step S02).

[0089] In step S09, when the request receiving component 60 receives a data acquisition request from the relay component 51, the request receiving component 60 transmits and receives information to and from the STS 30 and executes a verification process to confirm the validity of the qualification information added to the data acquisition request.

[0090] In step S09, if the validity of the qualification information is confirmed by both the STS 30 and the request receiving component 60, the request receiving component 60 acquires information indicating a list of components that relay (route) the data from the STS 30 while maintaining the relay (route) order, using a hash value calculated from the qualification information as a parameter (step S10). At this time, the list of components acquired from the STS 30 may include the time when the data passed through.

[0091] In step S11, when the request receiving component 60 receives information indicating a list of components from the STS 30, it transmits an attribute information acquisition request to the STS 30 to acquire information on the attributes of the components in the list. When the STS 30 receives the attribute information acquisition request from the request receiving component 60, it executes processing according to the attribute information acquisition request. At this time, if the STS 30 does not hold information on the attributes of each component, or if the STS 30 holds information on the attributes of each component but the held information is old, it acquires information on the attributes of each component from the authentication unit 70 which holds information on the attributes of each component (step S12).

[0092] After executing processing in accordance with the attribute information acquisition request, if STS 30 holds information regarding the attributes of each component, it returns the attribute information regarding the attributes of each component that it holds to the request receiving component 60 as a response to the attribute information acquisition request. Conversely, if STS 30 does not hold information regarding the attributes of each component, it returns the attribute information regarding the attributes of each component acquired from the authentication unit 70 to the request receiving component 60 as a response to the attribute information acquisition request (step S13).

[0093] In step S14, when the request receiving component 60 receives attribute information from the STS 30, it checks the component that relayed the data (the component through which the data passes) and its attribute. Note that the processes of S11 to S14 can be omitted if they are not required by the request receiving component 60.

[0094] Next, in step S15, the request receiving component 60 accesses the data storage device based on the URI (data access destination) attached to the data retrieval request received in step S08, reads the data requested in the data retrieval request from the data storage device, and transmits the read data to the relay component 51 as a response to the data retrieval request.

[0095] In step S16, the relay component 51 transmits the data received from the request receiving component 60 to the request sending component 40 as a response to the data acquisition request received in step S02. This enables the request sending component 40 to acquire the data requested in the data acquisition request.

[0096] In the user authorization system according to this embodiment, the STS 30 holds information about other entities through which the above-mentioned request passes, and when a route record request is received from a specific entity, the STS 30 provides the specific entity with information about the other entity. In this way, even if information about the components through which the request passes is not included in the qualification information as in the first and second embodiments, it is possible to provide the specific entity with information about the other entity, as in the first and second embodiments.

[0097] In the user authorization system according to this embodiment, the specific entity uses the provided information about the other entity to identify the other entity through which the request passes. In this way, the specific entity can identify the other entity as in the first and second embodiments, even if the credential information does not include information about the component through which the request passes, as in the first and second embodiments.

[0098] (4) Variations Since the user authorization system and user authorization method according to the modified embodiment have a configuration and operation that is almost the same as the user authorization systems and user authorization methods according to the above-mentioned embodiments, the same configurations and operations will not be described again, and the following description will focus on the differences. (4-1) First modified example 18 is a sequence diagram showing an example of a user authorization method in a user authorization system according to a first modified example. The user authorization system according to the first modified example is different from the above-mentioned first to third embodiments in that a plurality of relay components 51, 52 are provided, and information (routing information) regarding components to be traversed, including caseID, is recorded in STS 30. In the illustrated example, steps P01 to P03 are similar to steps F01 to F03 in the first embodiment.

[0099] In step P04, after the relay component 51 acquires the credential information using the authentication information in step P03, it transmits to the STS 30 a transit record and a credential information update request that includes the credential information of the relay component 51 acquired in step P03 and the credential information 13 added to the data acquisition request in P02.

[0100] In step P05, when the STS 30 receives a transit record and a credential information update request from the relay component 51, in order to confirm the validity of the credential information 13 and the credential information of the relay component 51, the STS 30 sends and receives information to and from the authentication unit 70 that issued each credential information, and confirms the validity of the credential information 13 and the credential information of the relay component 51.

[0101] In step P05, if both STS 30 and authentication unit 70 are able to confirm the validity of the credential information 13 and the credential information of relay component 51, STS 30 performs case ID numbering to link the series of route history, i.e., the history indicating which components the data acquisition request passed through, and records the identifier of the component that issued the route record and the credential information update request (in this case, relay component 51) and the time (the time when the route record and the credential information update request were received) and the case ID number (the number determined by the numbering) in the credential information history 34, and then updates the credential information 13 and the credential information of relay component 51 (step P06).

[0102] In step P07, when the STS 30 completes the processing of the route record and the credential information update, it sends information indicating that the processing of the route record and the credential information update has been completed and each updated credential information to the relay component 51 as a response to the route record and credential information update request.

[0103] In step P08, when the relay component 51 receives information that the processing of the route record and the credential information update has been completed, it sends to the relay component 52 a data acquisition request that takes into consideration the contents of the data acquisition request received from the request sending component 40 in step P02, that is, a data acquisition request that includes the credential information updated in step P06 and information such as the URI of the resource to be acquired that was received in step P02.

[0104] In step P09, when the relay component 52 receives a data acquisition request from the relay component 51, it transmits a credential information acquisition request including authentication information (e.g., a password) of the relay component 52 to the authentication unit 70. Furthermore, in step P09, when the authentication unit 70 performs authentication on the authentication information added to the credential information acquisition request, the authentication unit 70 transmits the credential information 100 shown in Fig. 6 as the credential information for the authentication information to the relay component 52. This allows the relay component 52 to acquire the credential information 100 using the authentication information.

[0105] Next, in step P10, the relay component 52 sends a route record request to the STS 30, including the credential information acquired in step P09 and the credential information sent from the relay 51 in step P08. In step P11, when the STS 30 receives a route record request from the relay component 52, it transmits and receives information to and from the authentication unit 70 that issued the credential information in order to confirm the validity of the credential information of the relay component 52.

[0106] In step P11, if both STS 30 and authentication unit 70 are able to confirm the validity of the credentials of relay component 52, STS 30 records the identifier of the component that issued the route record request (in this case, relay component 52) ​​and the time (the time the route record request was received) in the credentials history 34 in order to link the series of route history, and then updates the credentials of relay component 52 (step P12).

[0107] In step P13, when the STS 30 has completed the process of the route record, it transmits information indicating that the process of the route record has been completed and the updated qualification information to the relay component 52 as a response to the route record request.

[0108] When the relay component 52 receives the information that the process of the route record is completed, it transmits a data acquisition request including information such as the URI of the resource to be acquired received in step P08 to the request receiving component 60 (step P14). The data acquisition request is, for example, a request including the qualification information of the relay component 52 and the qualification information added to the data acquisition request in step P08.

[0109] When the request receiving component 60 receives a data acquisition request from the relay component 52, it transmits and receives information to and from the STS 30 and executes a verification process to check the validity of the qualification information added to the data acquisition request (step P15).

[0110] In step P15, if the validity of the qualification information is confirmed by both the STS 30 and the request receiving component 60, the request receiving component 60 obtains information indicating a list of components that have relayed the data (components through which the data passes) from the STS 30 with the case ID included in the qualification information as a parameter, while maintaining the relay (passage) order (step P16). At this time, the list of components obtained from the STS 30 may also include the time the data passed through.

[0111] When the request receiving component 60 receives information indicating a list of components from the STS 30, it transmits an attribute information acquisition request to the STS 30 to acquire information on the attributes of the components in the list (step P17). When the STS 30 receives an attribute information acquisition request from the request receiving component 60, it executes processing according to the attribute information acquisition request. At this time, if the STS 30 does not hold information on the attributes of each component, or if the STS 30 holds information on the attributes of each component but the held information is old, it acquires information on the attributes of each component from the authentication unit 70 which holds information on the attributes of each component (step P18).

[0112] After executing processing in accordance with the attribute information acquisition request, if STS 30 holds information regarding the attributes of each component, it replies to request receiving component 60 with the attribute information it holds regarding the attributes of each component as a response to the attribute information acquisition request; if STS 30 does not hold information regarding the attributes of each component, it replies to request receiving component 60 with the attribute information regarding the attributes of each component acquired from authentication unit 70 as a response to the attribute information acquisition request (step P19).

[0113] In step P20, when the request receiving component 60 receives attribute information from the STS 30, it checks the component that relayed the data (the component through which the data passes) and its attribute. Note that the processing of steps P16 to P20 can be omitted if the request receiving component 60 does not require it.

[0114] Next, the request receiving component 60 accesses the data storage device based on the URI (data access destination) attached to the data retrieval request received in step P14, reads the data requested in the data retrieval request from the data storage device, and transmits the read data to the relay component 52 as a response to the data retrieval request received in P14 (step P21).

[0115] The relay component 52 transmits the data received from the request receiving component 60 to the relay component 51 as a response to the data acquisition request received in P08 (step P22). The relay component 51 transmits the data received from the relay component 52 to the request sending component 40 as a response to the data acquisition request received in P02 (P23). This allows the request sending component 40 to acquire the data requested in the data acquisition request.

[0116] (4-2) Second modified example 19 is a sequence diagram showing an example of a user authorization method in a user authorization system according to a second modified example. The second modified example has a plurality of relay components compared to the second embodiment. In the illustrated example, steps R01 to R07 are similar to steps F01 to F07 in the first embodiment.

[0117] In step R08, if the relay component 51 receives information from the STS 30 in R07 indicating that the credential information update process has been completed, the relay component 51 transmits to the relay component 52 a data retrieval request taking into consideration the contents of the data retrieval request received from the request sending component 40 in R02, that is, a data retrieval request including the credential information acquired in step R07 and information such as the URI of the resource to be retrieved that has been received in step R02.

[0118] In step R09, when the relay component 52 receives a data acquisition request from the relay component 51, it transmits a credential information acquisition request including authentication information of the relay component 52, for example, a password, to the authentication unit 70. Furthermore, in step R09, when the authentication unit 70 performs authentication for the authentication information added to the credential information acquisition request, the authentication unit 70 transmits the credential information 100 shown in FIG. 6 as the credential information for the authentication information to the relay component 52. This allows the relay component 52 to obtain the credential information 100 using the authentication information. This credential information 100 is the credential information of the relay component 52.

[0119] Next, in step R10, the relay component 52 sends a credential information update request including the credential information acquired in R09 and the credential information sent in R08 to the STS 30. In step R11, when the STS 30 receives the credential information update request from the relay component 52, in order to confirm the validity of the credential information of the relay component 52, the STS 30 transmits and receives information to and from the authentication unit 70 that issued the credential information, and confirms the validity of the credential information of the relay component 52.

[0120] In step R11, if both the STS 30 and the authentication unit 70 are able to confirm the validity of the credentials of the relay component 52, the STS 30 updates the credentials 200 sent in R08 as requested in the credentials update request (step R12).

[0121] When updating the credential information 200 requested in the credential information update request, the STS 30 generates the credential information 200 shown in Fig. 7, which is the credential information to which a delegation term indicating that the credential information update request has been made by the relay component 52 instead of the relay component 51 has been added, and transmits the credential information 200 including the delegation term to the relay component 52. As a result, the STS 30 returns the credential information 200 including the delegation term as a response to the relay component 52 (step R13).

[0122] In step R14, when the relay component 52 receives the credential information 200 as a response from the STS 30, it refers to the data retrieval request received in R08 and sends a parameter data retrieval request to the request receiving component 60, the parameter data retrieval request including the contents of the parameters added to the data retrieval request (such as the URI of the resource to be retrieved) and the credential information 200 received in step R13.

[0123] In step R15, when the request receiving component 60 receives a data acquisition request from the relay component 52, the request receiving component 60 transmits and receives information to and from the STS 30 and executes a verification process to confirm the validity of the qualification information 200 added to the data acquisition request.

[0124] In step R14 described above, if both the STS 30 and the request receiving component 60 are able to confirm the validity of the credential information 200, the request receiving component 60 refers to the delegation terms (delegator ID, delegate ID) included in the credential information 200 received in step R09, and confirms the components through which the data acquisition request passes, for example, the relay components 51 and 52 (step R16). Note that the request receiving component 60 can omit the process of confirming the relay components through which the data acquisition request passes.

[0125] Next, in step R17, the request receiving component 60 accesses the data storage device as the data access destination based on the URI attached to the data retrieval request received in step R14 described above, reads the data requested in the data retrieval request from the data storage device, and transmits the read data to the relay component 52 as a response to the data retrieval request.

[0126] In step R18, the relay component 52 transmits the data received from the request receiving component 60 to the relay component 51 as a response to the data acquisition request received in R08. In step R19, the relay component 51 transmits the data received from the relay component 52 to the request sending component 40 as a response to the data acquisition request received in R02. This allows the request sending component 40 to acquire the data requested in the data acquisition request.

[0127] It should be noted that the present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations.

[0128] In addition, each of the configurations, functions, etc. described above may be realized in hardware, for example by designing some or all of them as an integrated circuit, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0129] Information such as programs, tables, files, etc. that realize each function can be stored in storage devices such as memory, hard disks, and SSDs (Solid State Drives), or recording media such as IC (Integrated Circuit) cards, SD (Secure Digital) cards, and DVDs (Digital Versatile Discs). [Explanation of symbols]

[0130] 1...user authorization system, 10...authentication unit, 20...authentication unit, 30...STS, 31...ID mapping, 32...credentials, 33...attribute mapping, 34...credentials history, 40...request sending component, 51...relay component, 60...request receiving component, 70...authentication unit, 80...authorization unit, 81...authorization policy

Claims

1. an authentication unit that manages authentication information, attribute information, and issued credential information for a plurality of entities involved in request exchange, such as a source and a destination of data that may be provided in response to a request, and an intermediate component through which the request may pass, and that authenticates the plurality of entities; a credential information generating unit that generates credential information including delegation terms based on credential information of one entity among the plurality of entities and credential information of another entity, and provides the credential information to a specific entity among the plurality of entities in response to the request; The qualification information generation unit, Based on the credential information generated by the credential information generating unit, the specific entity that received the credential information is provided with information about other entities via which the request is made. A user authorization system comprising:

2. The qualification information generation unit, Providing the particular entity with information about the other entities through which the request is made in the credential information 2. The user authorization system according to claim 1.

3. an authorization unit that determines whether or not to permit access to a source of the data based on the credential information generated by the credential information generation unit and based on an authorization policy; 3. The user authorization system according to claim 1 or 2.

4. The qualification information generation unit, Holds information about other entities through which the request may be made; Upon receiving a record route request, provide the particular entity with information about the other entity.

2. The user authorization system according to claim 1.

5. The particular entity is: Using the provided information about the other entities to determine which other entities to route through in response to the request.

5. The user authorization system according to claim 4.

6. an authentication step in which an authentication unit of the user authorization system manages authentication information, attribute information, and issued qualification information regarding a plurality of entities involved in request exchange, such as a source and a destination of data that may be provided in response to a request, and an intermediate component through which the request may pass, and authenticates the plurality of entities; a credential information generating step in which a credential information generating unit of the user authorization system generates credential information including a delegation term based on credential information of one entity among the plurality of entities and credential information of another entity, and provides the credential information to a specific entity among the plurality of entities in response to the request; In the qualification information generating step, The credential information generating unit provides, based on the credential information generated by the credential information generating unit, to the specific entity that has received the credential information, information regarding other entities via which the request is made. A user authorization method for a user authorization system comprising:

7. In the qualification information generating step, The credential information generating unit provides the specific entity with the credential information including information about the other entity via which the request is made. The user authorization method according to claim 6 .

8. an authorization step in which an authorization unit of the user authorization system determines whether or not to permit access to a source of the data based on the credential information generated by the credential information generation unit and on an authorization policy; 8. The user authorization method according to claim 6 or 7.

9. In the qualification information generating step, the credential generator holds information regarding other entities through which the request may be addressed; Upon receiving a record route request, provide the particular entity with information about the other entity. The user authorization method according to claim 6 .

10. The particular entity is: Using the provided information about the other entities to determine which other entities to route through in response to the request. The user authorization method according to claim 9 .

Images