WO2022259378A1 - 情報処理システム、リソース管理装置、リソース管理方法及びプログラム - Google Patents

情報処理システム、リソース管理装置、リソース管理方法及びプログラム Download PDF

Info

Publication number
WO2022259378A1
WO2022259378A1 PCT/JP2021/021784 JP2021021784W WO2022259378A1 WO 2022259378 A1 WO2022259378 A1 WO 2022259378A1 JP 2021021784 W JP2021021784 W JP 2021021784W WO 2022259378 A1 WO2022259378 A1 WO 2022259378A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
resource
scope
authority
modifier
Prior art date
Application number
PCT/JP2021/021784
Other languages
English (en)
French (fr)
Inventor
亮平 鈴木
浩司 千田
哲矢 奥田
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2023526690A priority Critical patent/JPWO2022259378A1/ja
Priority to PCT/JP2021/021784 priority patent/WO2022259378A1/ja
Publication of WO2022259378A1 publication Critical patent/WO2022259378A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present invention relates to an information processing system, resource management device, resource management method and program.
  • Non-Patent Document 1 OAuth is known as a technical specification for delegating partial authority to others (Non-Patent Document 1 and Non-Patent Document 2).
  • Players (characters) related to OAuth include the resource owner (RO), resource server (RS), relying party (RP), and authorization server (AS).
  • An RO is the owner of a resource such as data, and a user who uses the resource through a service provided by a third party.
  • the RS is the management destination of the resources of the RO (generally, the AS and the RS have the same management entity).
  • An RP is a third party that provides that certain service. In providing the service, the RP is delegated authority from the RO and accesses resources managed by the RS on behalf of the RO.
  • the AS performs delegation of access rights to resources to the RP.
  • the RO uses the RP's service.
  • the RO selects to link the AS and the RP (with access to the RP, the RO selects linking between the RP and the AS).
  • the RO is redirected from the RP to the AS and authorizes cooperation with the RP on the AS (agreeing to delegate authority).
  • the RP can obtain access tokens necessary to access resources managed by the RS.
  • the authority that is transferred to others is called scope.
  • the AS designs what kind of authority can be delegated, and publishes it as an API reference or the like.
  • the RP selects from the API reference the authority to use to provide the service.
  • the RO verifies the authority requested by the RP and delegates its authority to the RP if agreed.
  • the OAuth 2.0 Authorization Framework (RFC6749), [online], Internet ⁇ URL: https://tools.ietf.org/html/rfc6749>
  • the OAuth 2.0 Authorization Framework Bearer Token Usage (RFC6750), [online], Internet ⁇ URL: https://tools.ietf.org/html/rfc6750>
  • the present invention has been made in view of the above points, and aims to improve the flexibility of the scope of authority to be delegated to others.
  • a resource management device that manages a certain resource, an access device that accesses the resource, and the access authority when the owner of the resource permits delegation of the access authority to the resource. and an authorization device that issues an access token corresponding to the access token to the access device, wherein the resource management device responds to an access request to the resource accompanied by the access token from the access device by issuing the access token an acquisition unit that acquires information in which a modifier is assigned to the access authority disclosed in advance by the authorization device as information indicating the range of access authority corresponding to the access authority range limited by the modifier; and an execution unit that executes a process according to the access request.
  • FIG. 10 is a sequence diagram for explaining an example of a processing procedure when issuing an access token;
  • FIG. 10 is a diagram showing a display example of a screen for inquiring of a user about permission or disapproval of cooperation with the authorization server 20.
  • FIG. 11 is a diagram showing an example of an expanded menu on a screen for inquiring of a user about permission or denial of cooperation with the authorization server 20.
  • FIG. FIG. 10 is a sequence diagram for explaining an example of a processing procedure when issuing an access token;
  • FIG. 10 is a diagram showing a display example of a screen for inquiring of a user about permission or disapproval of cooperation with the authorization server 20.
  • FIG. FIG. 11 is a diagram showing an example of an expanded menu on a screen for inquiring of a user about permission or denial of cooperation with the authorization server 20.
  • FIG. 10 is a diagram showing a display example of a screen for inquiring about permission to transfer authority;
  • FIG. 10 is a diagram showing an example of an expanded menu on a screen for inquiring about permission to transfer authority;
  • FIG. 4 is a diagram conceptually showing the size (range) of scope;
  • FIG. 11 is a flowchart for explaining an example of a processing procedure when exercising an access token;
  • FIG. 1 is a diagram showing a configuration example of an information processing system according to an embodiment of the present invention.
  • the RO terminal 40, RP server 30, authorization server 20 and resource server 10 are connected via a network such as the Internet.
  • the RO terminal 40 is an owner of a certain software resource such as data (hereinafter referred to as "target resource”) and a user of a certain service (hereinafter referred to as "target service”) that accesses the target resource.
  • target resource a certain software resource such as data
  • target service a user of a certain service
  • a PC Personal Computer
  • smartphone a smartphone
  • tablet terminal or the like
  • the user corresponds to RO (resource owner) in OAuth.
  • the RP server 30 is one or more computers that provide target services. In order to provide the target service, the RP server 30 performs processing for receiving from the RO the transfer of authority for accessing the target resource. The processing complies with OAuth. Note that the RP server 30 functions as an RP (relying party) in OAuth.
  • the authorization server 20 is one or more computers that function as an AS in OAuth.
  • the resource server 10 is one or more computers that store and manage target resources and function as RSs in OAuth.
  • FIG. 2 is a diagram showing a hardware configuration example of the resource server 10 according to the embodiment of the present invention.
  • the resource server 10 of FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other via a bus B, respectively.
  • a program that implements processing in the resource server 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100 .
  • the program does not necessarily need to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores installed programs, as well as necessary files and data.
  • the memory device 103 reads and stores the program from the auxiliary storage device 102 when a program activation instruction is received.
  • the CPU 104 executes functions related to the resource server 10 according to programs stored in the memory device 103 .
  • the interface device 105 is used as an interface for connecting to a network.
  • the RP server 30, authorization server 20, and RO terminal 40 may also have the same hardware configuration as in FIG.
  • FIG. 3 is a diagram showing a functional configuration example of the information processing system according to the embodiment of the present invention.
  • the RP server 30 has an RPOAuth section 31 and a scope determination section 32 . Each of these units is realized by processing that one or more programs installed in the RP server 30 cause the CPU of the RP server 30 to execute.
  • the authorization server 20 has an ASOAuth section 21 , a scope setting section 22 and a scope verification section 23 . Each of these units is implemented by processing that one or more programs installed in the authorization server 20 cause the CPU of the authorization server 20 to execute.
  • the resource server 10 has an RSOAuth unit 11 and a scope analysis unit 12. Each of these units is implemented by processing that one or more programs installed in the resource server 10 cause the CPU 104 to execute.
  • FIG. 4 is a sequence diagram for explaining an example of a processing procedure when issuing an access token. Note that the processing procedure in FIG. 4 conforms to OAuth. Further, the process executed by the RO terminal 40 in FIG. 4 is, for example, a process that a web browser installed in the RO terminal 40 causes the RO terminal 40 to execute.
  • step S101 the RO terminal 40 transmits a request to use the target service to the RP server 30 in response to a predetermined operation by the user. It is assumed that the user has already been authenticated by the RP server 30 . Therefore, it is assumed that the RP server 30 can identify the user who requested the usage request.
  • the RPOAuth section 31 of the RP server 30 inquires of the scope determination section 32 about the scope value required for the target service (S102).
  • Scope means scope in OAuth.
  • Scope in OAuth means authority delegated to others.
  • a value that can be specified for scope (that is, the scope or type of authority) is published in advance by the authorization server 20 as an API reference or the like.
  • the list of scope values published in advance by the authorization server 20 will be referred to as a "default list”.
  • the scope determination unit 32 determines the scope required for the target service in response to the inquiry by the RPOAuth unit 31.
  • the determination by the scope determination unit 32 is performed based on preset setting information stored in the auxiliary storage device 102 or the like. That is, the setting information indicates the scope required for the target service.
  • a qualifier related to the period in which the resource was generated For example, scope. ⁇ YYYY/MM/DD ⁇ modifier can be considered. This qualifier means limiting access to resources created on a specific date (YYYY/MM/DD). scope. ⁇ YYYY/MM/DD-YYYY/MM/DD ⁇ , the period during which the resource is generated may be limited. At this time, "MM/DD" and "DD" may be omitted.
  • photo is one scope in the default list that indicates access rights to all photos
  • a setting such as “photo.span2020-2021” is possible.
  • “.span2020-2021” means a qualifier that limits the period of the photograph taken.
  • the scope determination unit 32 responds to the RPOAuth unit 31 with the applied scope with a modifier (S103).
  • the RPOAuth unit 31 responds to the RO terminal 40 with a redirect request for the authorization request including the scope with the modifier (S104).
  • a redirect request can include scope as a parameter.
  • the RO terminal 40 Upon receiving the response, the RO terminal 40 displays a screen asking the user whether or not the RP server 30 should cooperate with the authorization server 20.
  • FIG. 5 is a diagram showing a display example of a screen for inquiring of the user about permission or disapproval of cooperation with the authorization server 20.
  • FIG. 5 the part enclosed in ⁇ ⁇ is actually replaced with a specific service name or the like.
  • Screen 510 includes menu 511 . When the menu 511 is clicked by the user, the state of the screen 510 becomes as shown in FIG.
  • candidates 513 and 514 which are candidates for modifiers to be added to the scope with modifiers included in the redirect request, are displayed as options.
  • Such a candidate may be a modifier excluding modifiers that have already been assigned to the scope from among the list of modifiers that can be assigned to the original scope of the scope with the modifier. If the user wishes to limit the authority to be granted to the RP server 30 on his or her own will, the user can select one of the candidates and limit the authority according to the candidate.
  • the RO terminal 40 redirects the authorization request including the qualified scope to the authorization server 20 in response to the redirect request. (S105). Note that when the user selects the addition of a modifier via the screen 510 (when one of the modifier candidates is selected), the scope with the modifier is further given the added modifier. It becomes a thing.
  • the ASOAuth unit 21 of the authorization server 20 Upon receiving the redirected authorization request, the ASOAuth unit 21 of the authorization server 20 sends a verification request for the scope with the qualifier to the scope verification unit 23 if the scope included in the authorization request is the scope with the qualifier. (S106).
  • the scope verification unit 23 verifies the scope with the modifier in response to the verification request. For example, it is verified whether the scope is a scope for which a modifier is permitted, whether the value of the modifier is correct, and the like. That is, whether or not modifiers can be assigned, modifiers that can be assigned, and the like are defined in advance for each scope.
  • the scope verification unit 23 transmits the verification result (OK or NG) to the ASOAuth unit 21 (S107). If the verification result is OK, step S108 and subsequent steps are executed, and if NG, step S108 and subsequent steps are not executed.
  • step S108 the ASOAuth unit 21 performs authentication processing of the user of the RO terminal 40 (that is, the RO of the target resource) according to the conventional OAuth procedure.
  • the ASOAuth unit 21 transmits to the RO terminal 40 an inquiry as to whether or not the authority indicated by the qualified scope can be delegated (S109).
  • the RO terminal 40 displays a screen asking whether the authority can be delegated.
  • FIG. 7 is a diagram showing a display example of a screen for inquiring about permission to transfer authority.
  • the part enclosed in ⁇ ⁇ is actually replaced with a specific service name or the like.
  • Screen 520 includes menu 521 .
  • the menu 521 is clicked by the user, the state of the screen 520 becomes as shown in FIG.
  • candidate 523 and candidate 524 which are candidates for modifiers to be added to scope with modifiers indicating the authority, are displayed as options.
  • Such a candidate may be a modifier excluding modifiers that have already been assigned to the scope from among the list of modifiers that can be assigned to the original scope of the scope with the modifier. If the user wishes to limit his/her own authority, he/she can limit the authority according to the candidate by selecting one of the candidates.
  • the RO terminal 40 transmits a response indicating permission to delegate authority to the authorization server 20 (S110).
  • the response also includes a qualified scope. If the modifier has not been added by the user via the screen 520, the scope with the modifier is the same as that sent to the RO terminal 40 in step S109, and modified by the user via the screen 520. When a child is added, the added modifier is added.
  • the scope setting unit 22 of the authorization server 20 sets the qualified scope included in the response to the ASOAuth unit 21 (S111). If the set qualified scope has been changed from the qualified qualified scope verified in step S106 (if the qualified has been added), the ASOAuth unit 21 A scope verification request is sent to the scope verification unit 23 (S112). The scope verification unit 23 verifies the scope with the modifier in response to the verification request. The content of the verification may be the same as the verification request in response to step S106. Subsequently, the scope verification unit 23 transmits the verification result (OK or NG) to the ASOAuth unit 21 (S113). If the verification result is OK, step S114 is executed, and if NG, step S114 is not executed.
  • step S114 the ASOAuth unit 21 issues (transmits) an access token for the target resource to the RSOAuth unit 11 according to the procedure specified by OAuth.
  • S114 means a procedure for issuing an access token to the RP server 30, and the specific processing procedure is to be read according to the OAuth grant type.
  • the ASOAuth unit 21 stores the qualified scope corresponding to the access token.
  • the storage method of the qualified scope corresponding to the access token may comply with the storage method of the scope corresponding to the access token in OAuth.
  • the RP By exercising the access token (hereinafter referred to as the "target token"), the RP will be able to access the target resource.
  • the access token hereinafter referred to as the "target token”
  • the scope can be limited (qualifiers can be added to the scope) at the following three timings in the process before the access token is issued.
  • Timing of making an authorization request on the RP server 30 side when the user uses the service of the RP server 30 The user limits the scope (adds a modifier to the scope) via the screen 510 .
  • modifiers must be allowed to be added at all timings of (0) to (2) above, and modifiers can be added at any one or more timings. All you have to do is
  • FIG. 10 is a flowchart for explaining an example of a processing procedure when exercising an access token.
  • the processing procedure in FIG. 10 is executed, for example, after step S114 in FIG.
  • step S201 the RPOAuth unit 31 transmits an access request to the target resource along with the target token to the resource server 10 as a procedure conforming to OAuth.
  • the RSOAuth section 11 of the resource server 10 Upon receiving the access request and the target token, the RSOAuth section 11 of the resource server 10 sends a scope inquiry corresponding to the target token to the ASOAuth section 21 as a procedure conforming to OAuth (S202).
  • the query includes the target token.
  • the ASOAuth unit 21 transmits a response including the stored scope associated with the target token to the RSOAuth unit 11 (S203).
  • the scope with modifier is included in the response.
  • Specific contents of the response are, for example, as follows. "HTTP 200 OK Content-type: application/json ⁇ "scope”:"scope. ⁇ album_name ⁇ scope. ⁇ YYYY-MM-DD ⁇ ",... ⁇ ” That is, the response lists scopes corresponding to the target token, and assigns modifiers to the scopes.
  • the RSOAuth section 11 executes processing (access to the target resource) according to the access request from the RPOAuth section 31 within the scope of the access authority (S206).
  • the authority of the RPOAuth section 31 is limited based on the qualifier.
  • the RSOAuth unit 11 transmits the access result to the target resource to the RPOAuth unit 31 (S207).
  • the resource server 10 is an example of a resource management device.
  • the authorization server 20 is an example of an authorization device.
  • the RP server 30 is an example of an access device.
  • the RSOAuth unit 11 is an example of an acquisition unit and an execution unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

或るリソースを管理するリソース管理装置と、前記リソースへアクセスするアクセス装置と、前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に前記アクセス権限に対応するアクセストークンを前記アクセス装置に発行する認可装置とを含む情報処理システムにおいて、前記リソース管理装置は、前記アクセス装置からの前記アクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、を有することで、他者に委譲する権限の範囲の柔軟性を向上させる。

Description

情報処理システム、リソース管理装置、リソース管理方法及びプログラム
　本発明は、情報処理システム、リソース管理装置、リソース管理方法及びプログラムに関する。
　他者に部分的な権限を委譲するための技術仕様として、ＯＡｕｔｈが知られている（非特許文献１及び非特許文献２）。
　ＯＡｕｔｈに関するプレイヤ（登場人物）としては、リソースオーナ（ＲＯ）、リソースサーバ（ＲＳ）、リライングパーティ（ＲＰ）、認可サーバ（ＡＳ）が存在する。ＲＯは、データ等のリソースの所有者（オーナ）であり、サードパーティが提供する或るサービスを介して当該リソースを利用するユーザである。ＲＳは、ＲＯのリソースの管理先である（一般的にＡＳとＲＳの管理主体は同一である）。ＲＰは、当該或るサービスを提供するサードパーティである。ＲＰは、当該サービスの提供に際し、ＲＯから権限を委譲され、ＲＳに管理されているリソースに対してＲＯに代わってアクセスを実施する。ＡＳは、リソースに対するアクセス権限についてＲＰへの委譲の実施を行う。
　具体的には。まず、ＲＯがＲＰのサービスを利用する。その際、ＲＯは、ＡＳとＲＰを連携させることを選択する（ＲＰにアクセスした状態で、ＲＯは、ＲＰとＡＳとの連携を選択する）。ＲＯは、ＲＰからＡＳにリダイレクトされ、ＡＳ上でＲＰとの連携を認可する（権限の委譲を同意する）。その結果、ＲＰは、ＲＳが管理するリソースにアクセスするために必要なアクセストークンを入手することができる。
　ＯＡｕｔｈにおいて、他者に移譲する権限をｓｃｏｐｅという。ＡＳはどのような権限を委譲できるかを設計し、ＡＰＩリファレンスなどで公開する。ＲＰは、サービスを提供するために利用する権限をＡＰＩリファレンスから選択する。ＲＯは、ＲＰが要求する権限を確認し、同意した場合にＲＰに自身の権限を委譲する。
The OAuth 2.0 Authorization Framework (RFC6749)、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc6749＞ The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750)、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc6750＞
　しかしながら、上記の従来技術では、ＡＳが最初に設計したｓｃｏｐｅのみの指定となるため、ＲＰが提供するサービスに必要以上の権限がＲＰに委譲されてしまう可能性が有る。
　本発明は、上記の点に鑑みてなされたものであって、他者に委譲する権限の範囲の柔軟性を向上させることを目的とする。
　そこで上記課題を解決するため、或るリソースを管理するリソース管理装置と、前記リソースへアクセスするアクセス装置と、前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に前記アクセス権限に対応するアクセストークンを前記アクセス装置に発行する認可装置とを含む情報処理システムにおいて、前記リソース管理装置は、前記アクセス装置からの前記アクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、を有する。
　他者に委譲する権限の範囲の柔軟性を向上させることができる。
本発明の実施の形態における情報処理システムの構成例を示す図である。 本発明の実施の形態におけるリソースサーバ１０のハードウェア構成例を示す図である。 本発明の実施の形態における情報処理システムの機能構成例を示す図である。 アクセストークンの発行時の処理手順の一例を説明するためのシーケンス図である。 認可サーバ２０との連携の許否をユーザに問い合わせる画面の表示例を示す図である。 認可サーバ２０との連携の許否をユーザに問い合わせる画面におけるメニューが展開した例を示す図である。 権限の委譲の可否を問い合わせる画面の表示例を示す図である。 権限の委譲の可否を問い合わせる画面におけるメニューが展開した例を示す図である。 ｓｃｏｐｅの大きさ（範囲）を概念的に示す図である。 アクセストークンの行使時の処理手順の一例を説明するためのフローチャートである。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理システムの構成例を示す図である。
　図１において、ＲＯ端末４０、ＲＰサーバ３０、認可サーバ２０及びリソースサーバ１０は、インターネット等のネットワークを介して接続される。
　ＲＯ端末４０は、データ等の或るソフトウェアリソース（以下、「対象リソース」という。）の所有者であるとともに、対象リソースへアクセスする或るサービス（以下、「対象サービス」という。）の利用者であるユーザが利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等がＲＯ端末４０として利用されてもよい。なお、当該ユーザは、ＯＡｕｔｈにおけるＲＯ（リソースオーナ）に相当する。
　ＲＰサーバ３０は、対象サービスを提供する１以上のコンピュータである。ＲＰサーバ３０は、対象サービスを提供するために、対象リソースに対してアクセスするための権限の委譲をＲＯから受けるための処理を実行する。当該処理は、ＯＡｕｔｈに準拠する。なお、ＲＰサーバ３０は、ＯＡｕｔｈにおけるＲＰ（リライングパーティ）として機能する。
　認可サーバ２０は、ＯＡｕｔｈにおけるＡＳとして機能する１以上のコンピュータである。
　リソースサーバ１０は、対象リソースを記憶及び管理し、ＯＡｕｔｈにおけるＲＳとして機能する１以上のコンピュータである。
　図２は、本発明の実施の形態におけるリソースサーバ１０のハードウェア構成例を示す図である。図２のリソースサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
　リソースサーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってリソースサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　なお、ＲＰサーバ３０、認可サーバ２０及びＲＯ端末４０も図２と同様のハードウェア構成を有してよい。
　図３は、本発明の実施の形態における情報処理システムの機能構成例を示す図である。図３において、ＲＰサーバ３０は、ＲＰＯＡｕｔｈ部３１及びスコープ判定部３２を有する。これら各部は、ＲＰサーバ３０にインストールされた１以上のプログラムが、ＲＰサーバ３０のＣＰＵに実行させる処理により実現される。
　認可サーバ２０は、ＡＳＯＡｕｔｈ部２１、スコープ設定部２２及びスコープ検証部２３を有する。これら各部は、認可サーバ２０にインストールされた１以上のプログラムが、認可サーバ２０のＣＰＵに実行させる処理により実現される。
　リソースサーバ１０は、ＲＳＯＡｕｔｈ部１１及びスコープ解析部１２を有する。これら各部は、リソースサーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
　以下、情報処理システムが実行する処理手順について説明する。図４は、アクセストークンの発行時の処理手順の一例を説明するためのシーケンス図である。なお、図４の処理手順は、ＯＡｕｔｈに準拠したものである。また、図４においてＲＯ端末４０が実行する処理は、例えば、ＲＯ端末４０にインストールされたＷｅｂブラウザがＲＯ端末４０に実行させる処理である。
　ステップＳ１０１において、ＲＯ端末４０は、ユーザによる所定の操作に応じ、対象サービスの利用要求をＲＰサーバ３０へ送信する。なお、ユーザは、ＲＰサーバ３０によって認証済みであるとする。したがって、ＲＰサーバ３０は、当該利用要求の要求元のユーザを特定可能であるとする。
　ＲＰサーバ３０のＲＰＯＡｕｔｈ部３１は、当該利用要求を受信すると、対象サービスに必要なｓｃｏｐｅの値をスコープ判定部３２へ照会する（Ｓ１０２）。ｓｃｏｐｅとは、ＯＡｕｔｈにおけるｓｃｏｐｅをいう。ＯＡｕｔｈにおけるｓｃｏｐｅとは、他者へ委譲される権限をいう。ｓｃｏｐｅに指定可能な値（すなわち、権限の範囲又は種類）は、予め認可サーバ２０によってＡＰＩリファレンスなどで公開される。以下、認可サーバ２０によって予め公開されているｓｃｏｐｅの値のリストを「既定リスト」という。
　スコープ判定部３２は、ＲＰＯＡｕｔｈ部３１による照会に応じ、対象サービスに必要なｓｃｏｐｅを判定する。スコープ判定部３２による判定は、予め設定され、補助記憶装置１０２等に記憶されている設定情報に基づいて行われる。すなわち、当該設定情報が、対象サービスに必要なｓｃｏｐｅを示す。当該設定情報は、ＯＡｕｔｈについて必要とされる、ＡＳに対するＲＰ自身の登録申請（ＲＰのサービスの開発者のアカウントの登録の申請）時に、ＡＳに対して申請されたｓｃｏｐｅを示す。すなわち、申請には、連携先情報（ＲＰに関する情報）、表示名、連絡先、ユーザから委譲を希望する権限＝ｓｃｏｐｅ等の情報が必要とされる。なお、ＡＳが申請を許可した場合にのみ、ＲＰはＯＡｕｔｈを利用することができる。
　本実施の形態では、当該設定情報として、既定リストのうちのいずれかのｓｃｏｐｅに係るアクセス権限の範囲を更に限定する内容が設定可能である。既定リストの或る値を更に限定する場合、当該値に対して限定内容を示す識別子（以下、「修飾子」という。）が付与される。修飾子の一例としては、例えば、以下のようなものが考えられる。
　（ａ）リソースの構造関係（親・子の関係など）に関する修飾子
　例えば、リソースが写真の場合、
｛ｓｃｏｐｅ｝．｛ａｌｂｕｍ＿ｎａｍｅ｝
という修飾子が考えられる。ここで、｛ｓｃｏｐｅ｝は、既定リストのいずれかの値であり、「．｛ａｌｂｕｍ＿ｎａｍｅ｝」が修飾子を示す。当該修飾子は、ａｌｂｕｍ＿ｎａｍｅに係る特定のアルバム内の写真のみにアクセスを限定することを意味する。
　（ｂ）リソースが生成された期間に関する修飾子
　例えば、ｓｃｏｐｅ．｛ＹＹＹＹ／ＭＭ／ＤＤ｝
という修飾子が考えられる。当該修飾子は、特定の日付（ＹＹＹＹ／ＭＭ／ＤＤ）に生成されたリソースのみにアクセスを限定することを意味する。
ｓｃｏｐｅ．｛ＹＹＹＹ／ＭＭ／ＤＤ－ＹＹＹＹ／ＭＭ／ＤＤ｝
のように、リソースが生成された期間が限定されてもよい。この際、「ＭＭ／ＤＤ」や「ＤＤ」は省略されてもよい。
　例えば、「ｐｈｏｔｏ」は、全ての写真へのアクセス権限を示す、既定リストのうちの１つのｓｃｏｐｅであるとすると、「ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」といった設定が可能である。ここで、「．ｓｐａｎ２０２０－２０２１」は、撮影された写真の期間を限定する修飾子を意味する。したがって、「ｓｃｏｐｅ＝ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」は、撮影期間が２０２０年から２０２１年までの写真に対してのみに限定されたアクセス権限を示すことになる。
　（ｃ）リソースが生成された場所
　例えば、｛ｓｃｏｐｅ｝．｛建物名、都道府県名など｝
という修飾子が考えられる。当該修飾子は、特定の場所に関するリソースにのみアクセス権限を限定することを意味する。
　なお、上記したように、ＲＰの登録申請時にはｓｃｏｐｅの申請が必要であるが、本実施の形態では、修飾子付きのｓｃｏｐｅ（以下、「修飾子付きｓｃｏｐｅ」という。）が申請可能とされ、修飾子付きｓｃｏｐｅが申請されているとする。したがって、スコープ判定部３２は、申請済みの修飾子付きのｓｃｏｐｅをＲＰＯＡｕｔｈ部３１へ応答する（Ｓ１０３）。
　続いて、ＲＰＯＡｕｔｈ部３１は、当該修飾子付きｓｃｏｐｅを含む認可要求についてのリダイレクト要求をＲＯ端末４０へ応答する（Ｓ１０４）。当該リダイレクト要求の具体的な内容は、例えば、以下の通りである。
「HTTP/1.1 302 Moved Temporarily
Location: https://[ASの認可エンドポイント(公開情報)]/authorize?response_type=code&scope=photo&client_id=...」
　このように、本実施の形態では、リダイレクト要求にｓｃｏｐｅがパラメータとして含まれ得る。
　当該応答を受信したＲＯ端末４０は、ＲＰサーバ３０について認可サーバ２０との連携の許否をユーザに問い合わせる画面を表示する。
　図５は、認可サーバ２０との連携の許否をユーザに問い合わせる画面の表示例を示す図である。図５が示す画面５１０において、｛｝で囲まれている部分は、実際には具体的なサービス名等によって置き換えられる。画面５１０は、メニュー５１１を含む。メニュー５１１がユーザによってクリックされると、画面５１０の状態は、図６に示すようになる。
　図６では、リダイレクト要求に含まれている修飾子付きｓｃｏｐｅに対して更に付与する修飾子の候補である、候補５１３及び候補５１４が選択肢として表示されている。斯かる候補は、当該修飾子付きｓｃｏｐｅの元のｓｃｏｐｅに対して付与可能な修飾子の一覧のうち、既に当該ｓｃｏｐｅに付与されている修飾子を除く修飾子であってもよい。ユーザは、自らの意志でＲＰサーバ３０に認可する権限を限定したい場合は、いずれかの候補を選択することで、当該権限に対して当該候補に応じた限定を与えることができる。
　画面５１０を介して、認可サーバ２０との連携に対して許可を示す操作が行われると、ＲＯ端末４０は、当該リダイレクト要求に応じ、修飾子付きｓｃｏｐｅを含む認可要求を認可サーバ２０へリダイレクトする（Ｓ１０５）。なお、画面５１０を介してユーザによって修飾子の追加が選択された場合（いずれかの修飾子の候補が選択された場合）、当該修飾子付きｓｃｏｐｅは、更に、追加された修飾子が付与されたものとなる。
　認可サーバ２０のＡＳＯＡｕｔｈ部２１は、リダイレクトされた当該認可要求を受信すると、当該認可要求に含まれるｓｃｏｐｅが修飾子付きｓｃｏｐｅであれば、当該修飾子付きｓｃｏｐｅの検証要求をスコープ検証部２３へ送信する（Ｓ１０６）。スコープ検証部２３は、当該検証要求に応じ、当該修飾子付きｓｃｏｐｅを検証する。例えば、当該ｓｃｏｐｅが修飾子の付与が許可されているｓｃｏｐｅであるか、当該修飾子の値が正しいか等が検証される。すなわち、ｓｃｏｐｅ別に修飾子の付与の可否や、付与可能な修飾子等が予め規定されている。続いて、スコープ検証部２３は、検証結果（ＯＫ又はＮＧ）をＡＳＯＡｕｔｈ部２１へ送信する（Ｓ１０７）。当該検証結果がＯＫであればステップＳ１０８以降が実行され、ＮＧであればステップＳ１０８以降は実行されない。
　ステップＳ１０８において、ＡＳＯＡｕｔｈ部２１は、従来のＯＡｕｔｈの手順に従ってＲＯ端末４０のユーザ（すなわち、対象リソースのＲＯ）の認証処理を実行する。認証に成功すると、ＡＳＯＡｕｔｈ部２１は、修飾子付きｓｃｏｐｅが示す権限の委譲の可否の問い合わせをＲＯ端末４０へ送信する（Ｓ１０９）。
　ＲＯ端末４０は、当該問い合わせに応じ、当該権限の委譲の可否を問い合わせる画面を表示する。
　図７は、権限の委譲の可否を問い合わせる画面の表示例を示す図である。図７が示す画面５２０において、｛｝で囲まれている部分は、実際には具体的なサービス名等によって置き換えられる。画面５２０は、メニュー５２１を含む。メニュー５２１がユーザによってクリックされると、画面５２０の状態は、図８に示すようになる。
　図８では、当該権限を示す修飾子付きｓｃｏｐｅに対して更に付与する修飾子の候補である、候補５２３及び候補５２４が選択肢として表示されている。斯かる候補は、当該修飾子付きｓｃｏｐｅの元のｓｃｏｐｅに対して付与可能な修飾子の一覧のうち、既に当該ｓｃｏｐｅに付与されている修飾子を除く修飾子であってもよい。ユーザは、自らの当該権限を限定したい場合は、いずれかの候補を選択することで、当該権限に対して当該候補に応じた限定を与えることができる。
　画面５２０を介して、ＲＰサーバ３０に対する権限の委譲の許可を示す操作が行われると、ＲＯ端末４０は、権限の委譲の許可を示す応答を認可サーバ２０へ送信する（Ｓ１１０）。当該応答には、修飾子付きｓｃｏｐｅも含まれる。当該修飾子付きｓｃｏｐｅは、画面５２０を介してユーザによって修飾子の追加が行われていない場合は、ステップＳ１０９においてＲＯ端末４０へ送信されたものと同じであり、画面５２０を介してユーザによって修飾子の追加が行われている場合は、更に、追加された修飾子が付与されたものである。
　認可サーバ２０のスコープ設定部２２は、当該応答を受信すると、当該応答に含まれている修飾子付きｓｃｏｐｅをＡＳＯＡｕｔｈ部２１へ設定する（Ｓ１１１）。ＡＳＯＡｕｔｈ部２１は、設定された修飾子付きｓｃｏｐｅが、ステップＳ１０６において検証を受けた修飾子付きｓｃｏｐｅから変更されている場合（修飾子が追加されている場合）には、設定された修飾子付きｓｃｏｐｅの検証要求をスコープ検証部２３へ送信する（Ｓ１１２）。スコープ検証部２３は、当該検証要求に応じ、当該修飾子付きｓｃｏｐｅを検証する。検証の内容は、ステップＳ１０６に応じた検証要求と同じでよい。続いて、スコープ検証部２３は、検証結果（ＯＫ又はＮＧ）をＡＳＯＡｕｔｈ部２１へ送信する（Ｓ１１３）。当該検証結果がＯＫであればステップＳ１１４が実行され、ＮＧであればステップＳ１１４は実行されない。
　ステップＳ１１４において、ＡＳＯＡｕｔｈ部２１は、ＯＡｕｔｈに規定された手順に従って、対象リソースに対するアクセストークンをＲＳＯＡｕｔｈ部１１に対して発行（送信）する。なお、Ｓ１１４は、アクセストークンをＲＰサーバ３０に発行する手順を意味し、ＯＡｕｔｈのＧｒａｎｔ　ｔｙｐｅによって具体的な処理手順を読み替えるものとする。アクセストークンの発行に伴い、ＡＳＯＡｕｔｈ部２１は、当該アクセストークンに対応する修飾子付きｓｃｏｐｅを記憶しておく。アクセストークンに対応する修飾子付きｓｃｏｐｅの記憶方法は、ＯＡｕｔｈにおける、アクセストークンに対応するｓｃｏｐｅの記憶方法に準拠すればよい。
　ＲＰは、当該アクセストークン（以下、「対象トークン」という。）を行使することで、対象リソースへアクセス可能になる。
　なお、図４においては、アクセストークンが発行される前の過程における以下の３つのタイミングにおいて、ｓｃｏｐｅを限定することができる（ｓｃｏｐｅに対して修飾子を付与することができる）。
　（０）ＲＰがＡＳに登録する際のｓｃｏｐｅの提示のタイミング
　その結果として、ステップＳ１０３において修飾子付きｓｃｏｐｅが応答される。
　（１）ユーザがＲＰサーバ３０のサービスを利用する際に、ＲＰサーバ３０側で認可リクエストを行うタイミング
　ユーザが、画面５１０を介してｓｃｏｐｅを限定（ｓｃｏｐｅに修飾子を付与）する。
　（２）ユーザが認可サーバ２０を介してＲＰが提示した権限を認可するタイミング
　ユーザが、画面５２０を介してｓｃｏｐｅを限定（ｓｃｏｐｅに修飾子を付与）する。
　但し、上記の（０）～（２）の全てのタイミングにおいて修飾子の付与が可能とされなければならないことを意図したものではなく、いずれか１以上のタイミングで修飾子の付与が可能とされればよい。
　なお、上記のように３つのタイミングでｓｃｏｐｅを限定可能とした場合、図９に示されるように、ｓｃｏｐｅの大きさ（範囲）を多段階に限定することができる。
　次に、アクセストークンの行使について説明する。図１０は、アクセストークンの行使時の処理手順の一例を説明するためのフローチャートである。図１０の処理手順は、例えば、図４のステップＳ１１４に続いて実行される。
　ステップＳ２０１において、ＲＰＯＡｕｔｈ部３１は、ＯＡｕｔｈに準拠した手順として、対象トークンを伴って対象リソースへのアクセス要求をリソースサーバ１０へ送信する。
　リソースサーバ１０のＲＳＯＡｕｔｈ部１１は、当該アクセス要求及び対象トークンを受信すると、ＯＡｕｔｈに準拠した手順として、対象トークンに対応するｓｃｏｐｅの問い合わせをＡＳＯＡｕｔｈ部２１へ送信する（Ｓ２０２）。当該問い合わせには対象トークンが含まれる。
　ＡＳＯＡｕｔｈ部２１は、当該問い合わせに応じ、対象トークンに対応付けられて記憶されているｓｃｏｐｅを含む応答をＲＳＯＡｕｔｈ部１１へ送信する（Ｓ２０３）。本実施の形態では、修飾子付きｓｃｏｐｅが当該応答に含まれる。当該応答の具体的な内容は、例えば、以下の通りである。
「HTTP 200 OK
Content-type:application/json
{ "scope":"scope.{album_name} scope.{YYYY-MM-DD}"　,…}」
　すなわち、応答には、対象トークンに対応するｓｃｏｐｅが列挙され、当該ｓｃｏｐｅに修飾子が付与される。
　ＲＳＯＡｕｔｈ部１１は、当該応答を受信することで、当該応答に含まれている修飾子付きｓｃｏｐｅを取得する。続いて、ＲＳＯＡｕｔｈ部１１は、当該修飾子付きｓｃｏｐｅの意味（権限）の解析要求を、当該修飾子付きｓｃｏｐｅと共にスコープ解析部１２へ送信する（Ｓ２０４）。スコープ解析部１２は、当該解析要求に応じ、当該修飾子付きｓｃｏｐｅの意味を解析し、解析結果として、当該修飾子付きｓｃｏｐｅが意味するアクセス権限を含む応答をＲＳＯＡｕｔｈ部１１へ送信する（Ｓ２０５）。本実施の形態では、修飾子によって限定されたアクセス権限が応答される。例えば、修飾子付きｓｃｏｐｅが「ｓｃｏｐｅ＝ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」であれば、撮影期間が２０２０年から２０２１年までの写真についてのみのアクセス権限であることを示す応答が送信される。
　続いて、ＲＳＯＡｕｔｈ部１１は、当該アクセス権限の範囲内において、ＲＰＯＡｕｔｈ部３１からのアクセス要求に応じた処理（対象リソースへのアクセス）を実行する（Ｓ２０６）。その結果、ＲＰＯＡｕｔｈ部３１の権限が、修飾子に基づいて限定される。
　続いて、ＲＳＯＡｕｔｈ部１１は、対象リソースへのアクセス結果をＲＰＯＡｕｔｈ部３１へ送信する（Ｓ２０７）。
　上述したように、本実施の形態によれば、ｓｃｏｐｅに対して修飾子を付与することで、当初のｓｃｏｐｅの権限の範囲を限定することができる。したがって、他者に委譲する権限の範囲の柔軟性を向上させることができる。その結果、サービスに必要な範囲に移譲する権限を限定することができる。
　また、ユーザが修飾子を付与することができるため、ユーザに有利な権限の限定化が可能となる。その結果、ユーザが意図しない権限の委譲を回避できる可能性を高めることができる。
　なお、本実施の形態において、リソースサーバ１０は、リソース管理装置の一例である。認可サーバ２０は、認可装置の一例である。ＲＰサーバ３０は、アクセス装置の一例である。ＲＳＯＡｕｔｈ部１１は、取得部及び実行部の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　リソースサーバ
１１　　　　　ＲＳＯＡｕｔｈ部
１２　　　　　スコープ解析部
２０　　　　　認可サーバ
２１　　　　　ＡＳＯＡｕｔｈ部
２２　　　　　スコープ設定部
２３　　　　　スコープ検証部
３０　　　　　ＲＰサーバ
３１　　　　　ＲＰＯＡｕｔｈ部
３２　　　　　スコープ判定部
４０　　　　　ＲＯ端末
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス

Claims (6)

  1. 　或るリソースを管理するリソース管理装置と、前記リソースへアクセスするアクセス装置と、前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に前記アクセス権限に対応するアクセストークンを前記アクセス装置に発行する認可装置とを含む情報処理システムであって、
    　前記リソース管理装置は、
    　前記アクセス装置からの前記アクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、
    　前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、
    を有することを特徴とする情報処理システム。
  2. 　前記修飾子は、前記アクセストークンが前記アクセス装置へ発行されるまでの前において、前記アクセス装置によって付与される、
    ことを特徴とする請求項１記載の情報処理システム。
  3. 　前記修飾子は、前記アクセストークンが前記アクセス装置へ発行される前において、前記リソースの所有者によって付与される、
    ことを特徴とする請求項１又は２記載の情報処理システム。
  4. 　或るリソースを管理するリソース管理装置であって、
    　前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、
    　前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、
    を有することを特徴とするリソース管理装置。
  5. 　或るリソースを管理するリソース管理装置が、
    　前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得手順と、
    　前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行手順と、
    を実行することを特徴とするリソース管理方法。
  6. 　或るリソースを管理するリソース管理装置に、
    　前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得手順と、
    　前記修飾子によって限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行手順と、
    を実行させることを特徴とするプログラム。
PCT/JP2021/021784 2021-06-08 2021-06-08 情報処理システム、リソース管理装置、リソース管理方法及びプログラム WO2022259378A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023526690A JPWO2022259378A1 (ja) 2021-06-08 2021-06-08
PCT/JP2021/021784 WO2022259378A1 (ja) 2021-06-08 2021-06-08 情報処理システム、リソース管理装置、リソース管理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/021784 WO2022259378A1 (ja) 2021-06-08 2021-06-08 情報処理システム、リソース管理装置、リソース管理方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2022259378A1 true WO2022259378A1 (ja) 2022-12-15

Family

ID=84425947

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/021784 WO2022259378A1 (ja) 2021-06-08 2021-06-08 情報処理システム、リソース管理装置、リソース管理方法及びプログラム

Country Status (2)

Country Link
JP (1) JPWO2022259378A1 (ja)
WO (1) WO2022259378A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170034172A1 (en) * 2015-07-30 2017-02-02 Cisco Technology, Inc. Token scope reduction
JP2019200515A (ja) * 2018-05-15 2019-11-21 キヤノン株式会社 情報処理装置、情報処理方法、およびコンピュータプログラム
WO2019240793A1 (en) * 2018-06-14 2019-12-19 Hewlett-Packard Development Company, L.P. Access tokens with scope expressions of personal data policies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170034172A1 (en) * 2015-07-30 2017-02-02 Cisco Technology, Inc. Token scope reduction
JP2019200515A (ja) * 2018-05-15 2019-11-21 キヤノン株式会社 情報処理装置、情報処理方法、およびコンピュータプログラム
WO2019240793A1 (en) * 2018-06-14 2019-12-19 Hewlett-Packard Development Company, L.P. Access tokens with scope expressions of personal data policies

Also Published As

Publication number Publication date
JPWO2022259378A1 (ja) 2022-12-15

Similar Documents

Publication Publication Date Title
JP5357246B2 (ja) 統合認証のためのシステム、方法およびプログラム製品
US9407628B2 (en) Single sign-on (SSO) for mobile applications
JP6066647B2 (ja) デバイス装置、その制御方法、およびそのプログラム
JP6198477B2 (ja) 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム
US9374356B2 (en) Mobile oauth service
JP6166596B2 (ja) 認可サーバーシステムおよびその制御方法、並びにプログラム
EP2540051B1 (en) Method for managing access to protected resources and delegating authority in a computer network
US9043591B2 (en) Image forming apparatus, information processing method, and storage medium
US9143502B2 (en) Method and system for secure binding register name identifier profile
US9626137B2 (en) Image forming apparatus, server device, information processing method, and computer-readable storage medium
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
GB2489563A (en) Long term delegation of cloud/server data/resource access authorisation to applications by establishing token request rights
JP2002334056A (ja) ログイン代行システム及びログイン代行方法
WO2015042349A1 (en) Multiple resource servers with single, flexible, pluggable oauth server and oauth-protected restful oauth consent management service, and mobile application single sign on oauth service
JP2017220113A (ja) 認可サーバー、制御方法、およびプログラム。
JP2007048241A (ja) アクセス制御システム、アクセス制御方法およびアクセス制御プログラム
JP2016115260A (ja) 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム
JP2000106552A (ja) 認証方法
JP4573559B2 (ja) 分散認証システム、負荷分散装置及び認証サーバ、並びに負荷分散プログラム及び認証プログラム
WO2022259378A1 (ja) 情報処理システム、リソース管理装置、リソース管理方法及びプログラム
WO2014070269A1 (en) Methods and systems for managing directory information
Siriwardena et al. UMA Evolution
JP2024010384A (ja) シングルサインオン認証システムおよびシングルサインオン認証装置
Wilson et al. Sample Application with Custom API

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21945056

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18558449

Country of ref document: US

Ref document number: 2023526690

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21945056

Country of ref document: EP

Kind code of ref document: A1