JP2019096076A - アクセス制御システム、その制御方法およびプログラム - Google Patents

アクセス制御システム、その制御方法およびプログラム Download PDF

Info

Publication number
JP2019096076A
JP2019096076A JP2017225129A JP2017225129A JP2019096076A JP 2019096076 A JP2019096076 A JP 2019096076A JP 2017225129 A JP2017225129 A JP 2017225129A JP 2017225129 A JP2017225129 A JP 2017225129A JP 2019096076 A JP2019096076 A JP 2019096076A
Authority
JP
Japan
Prior art keywords
access token
region
resource
server
client
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
JP2017225129A
Other languages
English (en)
Inventor
存 田村
Tamotsu Tamura
存 田村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2017225129A priority Critical patent/JP2019096076A/ja
Priority to US16/196,971 priority patent/US10963554B2/en
Publication of JP2019096076A publication Critical patent/JP2019096076A/ja
Pending legal-status Critical Current

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
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • 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
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Storage Device Security (AREA)

Abstract

【課題】各リージョンの規則でアクセス制限される場合に、リージョンに応じて、リソースサーバーがクライアントからのアクセスを受け入れてよいか判断可能とする。【解決手段】ＷＡＮ１００上に構成されるアクセス制御システムにおいて、認可サーバーは、ＯＡｕｔｈオーナーがユーザーである場合、ユーザーの存在するリージョンでのみ利用可能なアクセストークンを発行する。リソースサーバーは、アクセストークンの利用可能なリージョンを自身のリージョンと比較し、クライアントからのアクセスを受け入れるか否か判断する。【選択図】図１

Description

本発明は、認証・認可処理によりリソースサービスへのアクセスを制御するアクセス制御システム、その制御方法およびプログラムに関する。
クラウドが一般化するに伴い、複数のサービスを連携させる機会はますます増加している。サービスとは、インターネット等のネットワークを介して接続されたサーバーが提供する機能、換言すれば、ウェブアプリケーションのことを指す。サービスを連携させることでサービス提供者は、ユーザーに通常のサービスに付加価値を加えた新たなサービスを提供することができる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。
すなわち、ユーザーが望んだ以上の情報がサービス間でやりとりされる虞があり、ユーザーデータや個人情報に関する情報の流出という課題がある。たとえばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現される可能性があるが、ユーザーが認識したサービス以外がユーザーデータや個人情報を操作できてはいけない。またサービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。
ＯＡｕｔｈによれば、たとえばある端末内のアプリケーションからクラウドサービスが管理するデータにアクセスする場合は、アプリケーションはデータの所有者であるユーザーの明示的な認可を得ることになっている。ユーザーが認可すると、アプリケーションはアクセスを認められたことを証明するトークン（以下、アクセストークン）を受け取り、以降のアクセスはそのアクセストークンを用いて実現できる。以下では、アクセストークンの発行のための操作を認可操作と称する。
また、データなどのリソースの所有者をＯＡｕｔｈオーナー、ＯＡｕｔｈオーナーの認可を受けてリソースを利用するものをＯＡｕｔｈクライアントと称する。サービス連携においては、あるサービスで管理されているリソースを利用する外部サービスもしくは外部アプリケーションが、前述のＯＡｕｔｈクライアントとして振る舞う。なおリソースの所有者であるＯＡｕｔｈオーナーは、ユーザーの場合もあれば、外部サービスや外部アプリケーション自身の場合もある。後者の場合はＯＡｕｔｈオーナーとＯＡｕｔｈクライアントが一致することになる。
昨今はアクセストークンとして、トークンＩＤ以外の他にも属性情報を持てるＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ（以下、ＪＷＴ）と呼ばれるトークンを用いる仕組みが検討されている。
認可サーバーは認可サーバーの秘密鍵を用いてアクセストークンに署名する。アクセストークンを受信したリソースサーバーは、認可サーバーの公開鍵で署名検証を行うことで、受信したアクセストークンが妥当であることを検証できる。
アクセストークンの検証を各々のリソースサーバーが行えるようになることで、従来は認可サーバーに集中していたアクセストークン検証処理の負荷が分散しボトルネックが解消されるため、システム全体のパフォーマンスの向上を期待できる。特許文献１において、ＯＡｕｔｈを利用したアクセストークンを発行する技術が開示されている。
特開２０１５−５２０２号公報
クラウドサービスにおけるリージョンとは、地理的に分離されたそれぞれの領域を表す。リージョンを分割する単位は、地域、国、共同体など、何でもよい。リージョン同士は互いに独立したサーバー群で構成されるため、認可サーバーもそれぞれのリージョンに独立して存在する。またアクセストークンは、リソースの所有者であるＯＡｕｔｈオーナーが、対応するリージョンの認可サーバーで権限委譲を許可することで発行される。認可サーバーがそれぞれのリージョンに存在するのと同様に、リソースサーバーもそれぞれのリージョンに存在する。
ここでＧｅｏＤＮＳと呼ばれる仕組みで、アクセス先の名前解決の要求に対し、要求元と地理的に近いサーバーのＩＰアドレスを返す技術がある。さらに、認可サーバーの公開鍵を各リージョンで共有し、どのリージョンのリソースサーバーからでも利用できることを考える。このようにすることで、ＯＡｕｔｈオーナーの権限を委譲されたＯＡｕｔｈクライアントは、他リージョンで発行されたアクセストークンを利用し、地理的に近いリージョンのリソースサーバーにアクセスできるようになる。地理的に近いリージョンのリソースサーバーへのアクセスにより、他リージョンのリソースサーバーへのアクセスと比べ、ネットワーク遅延を低減させることができるようになる。これはＩｏＴデバイスのように、日時バッチでデータをアップロードするのでなく、随時データをアップロードするデバイスにおいて重要である。
一方で、各リージョンに配備されたサーバーやサーバー内のデータは、各々のリージョンが存在する国などの規則に従った運用が求められる。たとえば欧州にはＧＤＰＲと呼ばれる個人のデータに関する規則があり、欧州リージョンにおいてはＧＤＰＲの遵守が求められる。このように個人データの域外への移転に関する規則があるため、ユーザーと紐付くデータは、地理的に近いリソースサーバーでなく、ユーザーが主として居住する地域と対応するリージョンのリソースサーバーにアップロードさせる必要がある。従ってＯＡｕｔｈクライアントは、各リージョンにおける規則も考慮し、データ送信先として、データの内容ごとに適切なリージョンを選択すべきである。
しかしＯＡｕｔｈクライアントによっては、どのリージョンにデータを送信するかを制御しない可能性がある。さらにリソースサーバーは、他リージョンの認可サーバーが付加した署名でも検証可能であるため、署名が妥当であれば、どのリージョンから送信されたユーザーデータであっても、アップロードされたデータを受け入れてしまう。各リージョンのデータ移転に関する規則を遵守する上では、このような事態が起きるのを防ぐべきである。
本発明は前述の課題を鑑みてなされたもので、本発明はアクセストークン検証の処理負荷は分散させつつ、リソースサーバーがユーザーデータを受け入れるのは、ユーザーが主とする地域に対応するリージョンのみとするよう制御することを目的とする。
本願発明におけるアクセス制御システムは、クライアントを有する端末、リソースを有するリソースサーバー、および認可サーバーを少なくとも含むアクセス制御システムであって、前記認可サーバーは、アクセストークンの検証を前記リソースサーバーで行うための署名付きアクセストークンを発行する発行手段を有し、前記リソースサーバーは、前記クライアントから送信されるリソース要求および前記署名付きアクセストークンを受信した場合、前記署名付きアクセストークンの署名検証を行い、前記署名付きアクセストークンが有効であるかを判断する判断手段と、前記署名付きアクセストークンに含まれるリージョンと前記リソースサーバーのリージョンを比較し、前記リソースサーバーのリージョンが前記署名付きアクセストークンに含まれているかを確認する確認手段と、前記判断手段により有効であると判断され、かつ前記確認手段により含まれていると確認されたことに応じて、前記リソース要求に対する処理を実行する実行手段と、を有することを特徴とする。
本発明によりアクセストークン検証の処理負荷は分散させつつ、リソースサーバーがユーザーデータを受け入れるのは、ユーザーが主とする地域に対応するリージョンのみとするよう制御することが可能になる。
ネットワーク構成を示す図である。 本発明の実施の形態に係るサーバーコンピューターの構成図である。 本実施の形態に係るモジュール構成図である。 本実施の形態に係るログイン・認可フローである。 本実施の形態に係るアクセストークン要求フローである。 本実施の形態に係るアクセストークン発行フローである。 本実施の形態に係るリソースアクセス処理である。 本実施の形態に係る画面例である。 本実施の第２の形態に係るモジュール構成図である。 本実施の第２の形態に係るアクセストークン発行フローである。 本実施の第３の形態に係るリモジュール構成図である。 本実施の第３の形態に係るリソースアクセス処理フローである。
以下、本発明を実施するための形態について図面を用いて説明する。本実施の形態に係るアクセス制御システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１１０、１５０および１６０は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１０、ＬＡＮ１５０、ＬＡＮ１６０）である。ここでＬＡＮ１５０およびＬＡＮ１６０はそれぞれ、欧州のＥｕｒｏｐｅリージョンおよび日本のＪａｐａｎリージョンに存在するとする。
１５１はユーザーの認証・認可および認証トークン・アクセストークンの発行および検証を行う認証・認可サーバー、１５２はリソースを管理するリソースサーバーである。認証トークンとは、あるユーザーがシステムの正当な利用者であることを証明するものである。またアクセストークンとは、リソースの所有者がアプリケーションをはじめとするクライアントに対して、なんらかの操作を行うことを許可したことを証明するものであり、リソースの所有者がアプリケーションに対してリソースアクセスを認可することで発行される。たとえばクラウドサービスが管理するリソースにアクセスするためのアクセストークンを用いると、アプリケーションは、ユーザーに許可された範囲でリソースにアクセスできるようになる。
認証・認可サーバー１５１およびリソースサーバー１５２はＥｕｒｏｐｅリージョンに存在し、Ｅｕｒｏｐｅリージョン内で動作する。同様にＪａｐａｎリージョンにも認証・認可サーバー１６１およびリソースサーバー１６２が存在する。１１１はアプリケーションが動作する端末である。認証・認可サーバー１５１およびリソースサーバー１５２はそれぞれＬＡＮ１５０を介して、認証・認可サーバー１６１およびリソースサーバー１６２はそれぞれＬＡＮ１６０を介して、ＷＡＮ１００と接続されている。また同様に端末１１１はＬＡＮ１１０を介してＷＡＮ１００と接続されている。
なお認証・認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよいし、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認証・認可サーバー１５１、リソースサーバー１５２は図１ではそれぞれが1台として描かれているが複数のサーバーから構成されたサーバーシステムでも良く、例えば、複数台のサーバーをクラスタ化して認証・認可サーバー１５１を構成しても良い。同様に認証・認可サーバー１６１、リソースサーバー１６２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよいし、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認証・認可サーバー１６１、リソースサーバー１６２は図１ではそれぞれが1台として描かれているが複数のサーバーから構成されたサーバーシステムでも良く、例えば、複数台のサーバーをクラスタ化して認証・認可サーバー１６１を構成しても良い。なお、本願発明においてサーバーシステムと称した場合は、少なくとも1台のサーバーから構成された特定のサービスを提供する装置を指すものとする。
本実施の形態に係るデータ管理システムは、図２に示すような構成のＰＣから成るシステム上に実現される。図２は本実施の形態に係る、認証・認可サーバー１５１の構成を示す図である。またリソースサーバー１５２、認証・認可サーバー１６１、リソースサーバー１６２の構成や端末１１１の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。
図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。
図３は本実施の形態に係る、認証・認可サーバー１５１、リソースサーバー１５２、端末１１１のモジュール構成を示す図である。なお認証・認可サーバー１６１、リソースサーバー１６２はそれぞれ、認証・認可サーバー１５１、リソースサーバー１５２と同様の構成である。図３（Ａ）は認証・認可サーバー１５１、図３（Ｂ）はリソースサーバー１５２のモジュール構成を、それぞれ示す。また図３（Ｃ）は端末１１１のモジュール構成を示す。認証・認可サーバー１５１は認証モジュール３０１、認可モジュール３０２、認可済みスコープ管理モジュール３０３、アクセストークン発行モジュール３０４を持つ。また認証・認可サーバー１５１はさらに、クライアント公開鍵管理モジュール３０５、認証・認可サーバー秘密鍵管理モジュール３０６、リージョン決定モジュール３１０、ユーザー管理モジュール３１１、クライアント管理モジュール３１２を持つ。リソースサーバー１５２はリソースアクセス処理モジュール３５１、リージョン記憶モジュール３５２、認証・認可サーバー公開鍵管理モジュール３５３を持つ。端末１１１はアクセストークン要求モジュール３９１、クレデンシャル管理モジュール３９２、リソース要求モジュール３９３を持つ。
認証モジュール３０１はユーザーからの認証要求に応じユーザー認証および認証トークンの発行を行う。また認可モジュール３０２は、同じくユーザーからの認可操作に応じ、認可確認画面を表示して、ユーザーに権限委譲を促す。認可済みスコープ管理モジュール３０３は、ユーザーが権限委譲した認可済みスコープを記憶する。アクセストークン発行モジュール３０４は端末１１１のアクセストークン要求モジュール３９１によるアクセストークン要求に応じ、アクセストークンの発行を行う。このときアクセストークン要求は端末１１１のクレデンシャル管理モジュール３９２が管理するクライアントの秘密鍵で署名される。また署名の検証はクライアント公開鍵管理モジュール３０５で管理される公開鍵で行われる。このとき発行するアクセストークンは、リージョン決定モジュール３１０で決定されたリージョン情報を含み、認証・認可サーバー秘密鍵管理モジュール３０６で管理する認証・認可サーバーの秘密鍵によって署名される。認証・認可サーバーの秘密鍵で署名されたアクセストークンは、対応する公開鍵を用いて内容の妥当性を検証できる。ユーザー管理モジュール３１１およびクライアント管理モジュール３１２はそれぞれ、認証・認可サーバー１５１を利用するユーザーおよびクライアントを管理する。
リソースアクセス処理モジュール３５１は端末１１１のリソース要求モジュール３９３からリソース要求を受信する。リソース要求を受信したリソースアクセス処理モジュール３５１は、リージョン記憶モジュール３５２で記憶しているリージョン情報とアクセストークンに記載されたリージョン情報を比較する。さらに認証・認可サーバー公開鍵管理モジュールで３５３管理している認証・認可サーバーの公開鍵を用いて署名検証を行い、妥当と判断されたリソース要求を正常に処理する。
図４（Ａ）は本実施の形態に係る、認証・認可サーバー１５１におけるログインフローである。本フローは認証・認可サーバー１５１がユーザーからログイン要求を受信することで開始される。ステップＳ４０１で認証モジュール３０１は、図８（Ａ）に示されるようなログイン画面１００１を表示する。ステップＳ４０２で認証モジュール３０１は、ログイン画面１００１で入力された認証情報を受け付ける。ステップＳ４０３で認証モジュール３０１は、ステップＳ４０２で受け付けた認証情報が妥当であり、ログインを要求するユーザーが認証される正規なユーザーであるか判断する。ここで認証情報が妥当と判断された場合はステップＳ４０４に遷移する。また認証情報が妥当でないと判断された場合はステップＳ４３０に遷移する。
ステップＳ４０４で認証モジュール３０１は、ユーザーのログインを許可し、認証トークンを発行してフローを終了する。ステップＳ４３０で認証モジュール３０１は、ユーザーのログインを拒否し、フローを終了する。なお本実施の形態に係るログインフローには、一般的なログインフローを適用できるものとする。
図４（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における認可フローである。本フローは認証・認可サーバー１５１の認可モジュール３０２がユーザーからの認可要求を受信することで開始される。ステップＳ４５１で認可モジュール３０２は、ユーザーから認可要求を受け付ける。ここで受け付けた認可要求は、権限委譲先であるクライアントおよび権限委譲の対象となるスコープの情報を含む。
ステップＳ４５２で認可モジュール３０２は、図８（Ｂ）に示すような認可確認画面１００２を表示し、ユーザーの確認を求める。ステップＳ４５３で認可モジュール３０２は、ステップＳ４５２でユーザーの認可を得られたか判断する。ここで認可を得られたと判断された場合はステップＳ４５４に遷移する。また認可を得られなかったと判断された場合はステップＳ４６０に遷移する。ユーザーが認可を行うために図８（Ｂ）にて許可を選択するための操作を認可操作と称し、ユーザーにより認可操作が行われたことで、後述の図６のフローでアクセストークンの発行が行えるようになる。またここで認可された内容、すなわちアクセス可能なリソースの範囲をスコープと称する。
ステップＳ４５４で認可済みスコープ管理モジュール３０３は、ステップＳ４５２で実施された認可の内容を認可済みスコープテーブルで記憶してフローを終了する。表１は認可済みスコープテーブルで記憶する情報の例である。
Figure 2019096076
表１ではたとえば、ユーザー識別子「Ｕｓｅｒ００１」で示されるユーザーが、クライアント識別子「Ｃｌｉｅｎｔ００１」で示されるクライアントに対し、「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」の利用を認可していることを表す。ステップＳ４６０で認可モジュール３０２は、認可が行われなかった旨を通知し、フローを終了する。なお本実施の形態に係る認可フローには、一般的な認可フローを適用できるものとする。
図５は本実施の形態に係る、端末１１１におけるアクセストークン要求のフローである。本フローはユーザーの操作や、端末１１１内のスケジュールやなんらかのイベントをトリガとして開始される。なお以下では、端末１１１は、Ｅｕｒｏｐｅリージョンに存在する認証・認可サーバー１５１に対してアクセストークンを要求する場合の例を用いて図５のフローを説明する。
ステップＳ５０１でアクセストークン要求モジュール３９１は、トリガに応じて実施すべき処理に必要なスコープを判断する。たとえばここでは、ＳｃｏｐｅＡおよびＳｃｏｐｅＢが必要だとする。ステップＳ５０２でアクセストークン要求モジュール３９１は、クレデンシャル管理モジュール３９２からクライアント秘密鍵を取り出す。表２はクレデンシャル管理モジュール３９２が管理するクレデンシャル情報の例を表す。
Figure 2019096076
ここではクライアントの識別子が「Ｃｌｉｅｎｔ００１」であることと、クライアント秘密鍵およびクライアント鍵ＩＤがそれぞれ「Ｂｋ３ＴＬＤｆｏｚｃ４Ｆ」および「Ｃｌｉｅｎｔ００１Ｋｅｙ１」であることが示されている。ステップＳ５０３でアクセストークン要求モジュール３９１は、アクセストークンリクエストを生成し、ステップＳ５０２で取り出したクライアント秘密鍵を用いて署名を付与する。以下はアクセストークンリクエストの例である。アクセストークンリクエストはＪＷＴフォーマットで記述される。

{
"kid": "Client001Key1",
"typ":"JWT",
"alg": "RS256"
}
{
"iss": "Client001",
"sub": "User001",
"aud": "https://europe.authorization.example.com/",
"exp": 1508890200,
"iat": 1508889600,
"jti": "01234567890123456789012345678901234567890123456789",
"authz:scopes": [
"ScopeA",
"ScopeB"
]
}
上記のハッシュ値にクライアント秘密鍵で署名したものを付加し、アクセストークン要求が行われる。
ここでｋｉｄはアクセストークンリクエストに付与された署名のクライアント鍵ＩＤを表す。ａｌｇは署名に用いられたアルゴリズムを表し、ここではＲＳ２５６（ＲＳＡＳＳＡ−ＰＫＣＳ１＿ｖ１＿５ ｕｓｉｎｇ ＳＨＡ−２５６）が用いられていることを示す。またｔｙｐはアクセストークンリクエストがＪＷＴフォーマットであることを表す。またその他の項目についてはそれぞれ以下を表す。すなわち、ｉｓｓはＪＷＴの発行者の識別子、ｓｕｂはＪＷＴの主語となる主体の識別子、ａｕｄはＪＷＴを利用することが想定された主体の識別子一覧を表す。またｅｘｐはＪＷＴの有効期限、ｉａｔはＪＷＴの発行日時、ｊｔｉはＪＷＴのための一意な識別子、およびａｕｔｈｚ：ｓｃｏｐｅｓは要求するアクセストークンに含まれることを期待するスコープを表す。上記ｅｘｐ、ｉａｔに指定する日時はＩｎｔＤａｔｅで、１９７０−０１−０１Ｔ０：０：０ＺＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表すＪＳＯＮ数値である。なお本実施の形態に係るアクセストークンリクエストは上記フォーマットに限定されるものでなく、一般的なフォーマットを適用できるものとする。
上記の例では、ＪＷＴの発行者ｉｓｓは「Ｃｌｉｅｎｔ００１」であり、ｓｕｂで示される「Ｕｓｅｒ００１」の権限を委譲されたアクセストークンを、ａｕｄのＵＲＩで示されるＥｕｒｏｐｅの認証・認可サーバー１５１に対して要求している。要求している権限の範囲を表すスコープはａｕｔｈｚ：ｓｃｏｐｅｓで示される「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」である。このアクセストークンリクエストはｉａｔの値「１５０８８８９６００」で示される２０１７年１０月２５日０時０分０秒（ＵＴＣ）に発行された。また有効期限はｅｘｐの値「１５０８８９０２００」で示される２０１７年１０月２５日０時１０分０秒（ＵＴＣ）までである。
ＯＡｕｔｈの観点で見た場合、ｉｓｓに記載されるのは権限の委譲を受けるＯＡｕｔｈクライアントであり、アクセストークンを要求するクライアントのクライアント識別子が用いられる。またｓｕｂに記載されるのは権限を委譲するＯＡｕｔｈオーナーである。ＯＡｕｔｈオーナーは図４（Ｂ）のフローで認可操作をするユーザーの場合もあり、またアクセストークンを要求するクライアント自身の場合もある。さらにクライアントにはユーザーが所属するテナントと同じテナントに所属する形態や、ユーザーが所属するテナントには所属しない形態も存在する。
ステップＳ５０４でアクセストークン要求モジュール３９１は、ステップＳ５０３で生成した署名済みアクセストークンリクエストを認証・認可サーバー１５１に送信する。ステップＳ５０５でアクセストークン要求モジュール３９１は、ステップＳ５０４で送信したアクセストークンリクエストの応答として、認証・認可サーバー１５１からアクセストークンを受信し、フローを終了する。
図６は本実施の形態に係る、認証・認可サーバー１５１におけるアクセストークン発行のフローである。本フローは認証・認可サーバー１５１が、図５のステップＳ５０４で端末１１１のアクセストークン要求モジュール３９１から送信されたアクセストークン要求を受けて開始される。なお以下ではＥｕｒｏｐｅリージョンの認証・認可サーバー１５１のフローとして説明をしているが、Ｊａｐａｎリージョンの認証・認可サーバー１６１がアクセストークン要求を受信した場合のアクセストークン発行のフローも同様である。
ステップＳ６０１でアクセストークン発行モジュール３０４は、受信したアクセストークンリクエストに含まれるクライアント鍵ＩＤを取り出す。ステップＳ６０２でアクセストークン発行モジュール３０４は、ステップＳ６０１で取り出したクライアント鍵ＩＤをもとに、クライアント公開鍵管理モジュール３０５からクライアント公開鍵およびクライアント識別子を取り出す。表３はクライアント公開鍵管理モジュール３０５内で管理されるクライアント公開鍵管理テーブルの例である。
Figure 2019096076
表３によると、ステップＳ６０１で取り出したクライアント鍵ＩＤが「Ｃｌｉｅｎｔ００１Ｋｅｙ１」だった場合、取り出されるクライアント識別子およびクライアント公開鍵はそれぞれ「Ｃｌｉｅｎｔ００１」と「ＺＲＵ＋５ｗ／ＣｍＨ７／」となる。
ステップＳ６０３でアクセストークン発行モジュール３０４は、本フローの冒頭で受信したアクセストークンリクエストの署名を、ステップＳ６０２で取り出したクライアント公開鍵で検証する。またあわせて、アクセストークンリクエストに含まれるｉｓｓがステップＳ６０２で取り出したクライアント識別子と一致するか検証する。ステップＳ６０４でアクセストークン発行モジュール３０４は、ステップＳ６０３の検証結果に問題がないか判断する。問題がなかったと判断された場合はステップＳ６０５へ、問題があったと判断された場合はステップＳ６３０へ、それぞれ遷移する。
ステップＳ６０５でアクセストークン発行モジュール３０４は、本フローの冒頭で受信したアクセストークンリクエストから、ＯＡｕｔｈオーナー情報およびＯＡｕｔｈクライアント情報を取り出す。これはそれぞれ、アクセストークンのｓｕｂおよびおｉｓｓに記載されている。ステップＳ６０６でアクセストークン発行モジュール３０４は、ステップＳ６０５で取り出したＯＡｕｔｈオーナーとＯＡｕｔｈクライアントが一致するか判断する。一致しないと判断された場合はステップＳ６０７に遷移する。また一致すると判断された場合はステップＳ６１４に遷移する。
ステップＳ６０７でアクセストークン発行モジュール３０４は、アクセストークンリクエストのｓｕｂで示されるＯＡｕｔｈオーナーの情報を、ユーザー管理モジュール３１１に問い合わせる。表４はユーザー管理モジュール３１１のユーザー管理テーブルの例である。
Figure 2019096076
ここではＥｕｒｏｐｅリージョンの認証・認可サーバー１５１について説明をしているため、ユーザー管理モジュール３１１が管理するユーザー情報も、Ｅｕｒｏｐｅリージョンの認証・認可サーバー１５１のものである。Ｊａｐａｎリージョンの認証・認可サーバー１６１においては、ユーザー管理モジュール３１１が管理するユーザー情報は、Ｊａｐａｎリージョンの認証・認可サーバー１６１のものとなる。
ステップS６０８でアクセストークン発行モジュール３０４は、ステップＳ６０７でＯＡｕｔｈオーナーの情報を取得できたか判断する。取得できたと判断された場合はステップＳ６０９に遷移し、取得できなかったと判断された場合はステップＳ６３１に遷移する。なおＯＡｕｔｈオーナー情報をユーザー管理モジュール３１１から取得できたことで、以下のステップＳ６０９からステップＳ６１３においては、ＯＡｕｔｈオーナーがユーザーであるとして処理を行うことになる。
ステップＳ６０９でアクセストークン発行モジュール３０４は、ステップＳ６０５で取り出したＯＡｕｔｈオーナーとＯＡｕｔｈクライアントに関する認可済みスコープを、認可済みスコープ管理モジュール３０３から取り出す。具体的には、図４(B)における認可フローによって認可情報が記憶されることでスコープを取得することができる。たとえば、ＯＡｕｔｈオーナーが「Ｕｓｅｒ００１」であり、ＯＡｕｔｈクライアントが「Ｃｌｉｅｎｔ００１」の場合、認可済みスコープ情報として「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」が取り出される。
ステップＳ６１０でアクセストークン発行モジュール３０４は、認可フローによって認可情報が記憶されたこにより認可設定が存在するか否かを判断する。存在すればステップＳ６１１に遷移し、存在しなければステップＳ６３２に遷移する。ステップＳ６１１でアクセストークン発行モジュール３０４は、本フローの冒頭で受信したアクセストークンリクエストから、要求されたスコープを取り出す。
ステップＳ６１２でアクセストークン発行モジュール３０４は、ステップＳ６１１で取り出した要求されたスコープが認可されているか判断する。具体的には、ステップＳ６１１で取り出した要求されたスコープが、ステップＳ６０９で取り出した認可済みスコープに含まれるか判断する。認可されていると判断された場合はステップＳ６１３に遷移し、認可されていないと判断された場合はステップＳ６３２に遷移する。たとえばステップＳ６０９で取り出した認可済みスコープが「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」で、ステップＳ６１１で取り出した要求されたスコープが「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」の場合は、認可されていると判断される。
ステップＳ６１３でリージョン決定モジュール３１０は、ステップＳ６０７で取得したユーザーの所属リージョンを、アクセストークンの利用可能リージョンと決定する。これは、ＯＡｕｔｈオーナー情報をユーザー管理モジュール３１１から取得できたことで、ＯＡｕｔｈオーナーがユーザーであるとして処理しているためである。ＯＡｕｔｈオーナーがユーザーの場合、アクセストークンは、ユーザーの所属リージョンでのみ利用できるよう制御する必要がある。アクセストークンの利用可能リージョンを決定すると、ステップＳ６２１に遷移する。
一方、ステップＳ６１４でリージョン決定モジュール３１０は、ステップＳ６０５で取り出したＯＡｕｔｈクライアントがユーザーと関連付けられているか判断する。判断の結果ＯＡｕｔｈクライアントがユーザーと関連付けられていればステップＳ６１５に遷移し、関連付けられてなければステップＳ６１６に遷移する。
ＯＡｕｔｈオーナーがユーザーに関連付けられているか否かの判断は、たとえば以下のように行われる。まずリージョン決定モジュール３１０は、アクセストークンリクエストのｓｕｂで示される主体の識別子を用いて、クライアント管理モジュール３１２からクライアント情報を取得する。表５はクライアント管理モジュール３１２のクライアント管理テーブルの例である。たとえば、所属テナント「１００１E」には特定のユーザーである「User001」が関連付けられているため、クライアントが所属するテナントはユーザーデータを操作できると考える。
Figure 2019096076
次にリージョン決定モジュール３１０は、取得したクライアント情報の所属テナントをもとに、ユーザー管理モジュール３１１に対して、同じテナントに所属するユーザーが存在するかを確認する。ここでクライアントが所属するテナントにユーザー情報が関連付けられている場合、前述のクライアントはユーザーデータを操作できると考えられる。そのためアクセストークンの利用可能リージョンは制限すべきである。以上のように、ＯＡｕｔｈオーナーであるクライアントが、ユーザーが存在するテナントに所属しているか否かで、ユーザーに関連付けられているか否かを判断する。
ただし、クライアントであるＯＡｕｔｈオーナーがユーザーに関連付けられているか否かの判断は前述の方式に限定されるものではない。たとえばクライアントであるＯＡｕｔｈオーナーが所属するテナントと、ユーザーが所属するテナントとの対応関係を確認する方式でもよく、その他の方式でもよい。ステップＳ６１５でリージョン決定モジュール３１０は、ステップＳ６１４でクライアントであるＯＡｕｔｈオーナーと関連付けられていると判断されたユーザーの情報をユーザー管理モジュール３１１から取り出す。また取り出したユーザーの所属リージョンをアクセストークンの利用可能リージョンとして決定する。アクセストークンの利用可能リージョンを決定すると、ステップＳ６２１に遷移する。
ステップＳ６１６でリージョン決定モジュール３１０は、ステップＳ６１４でクライアントであるＯＡｕｔｈオーナーがユーザーと関連付かないと判断されたことを受け、アクセストークンの利用可能リージョンを制限しないこととする。そのためリージョン決定モジュール３１０は、すべてのリージョンをアクセストークンの利用可能リージョンとして決定する。アクセストークンの利用可能リージョンを決定すると、ステップＳ６２１に遷移する。ステップＳ６２１でアクセストークン発行モジュール３０４は、ステップＳ６１２、ステップＳ６１５、もしくはステップＳ６１６のいずれかで決定した利用可能リージョン情報を含むアクセストークンを生成する。
ステップＳ６２２でアクセストークン発行モジュール３０４は、認証・認可サーバー秘密鍵管理モジュール３０６から認証・認可サーバー１５１の秘密鍵を取り出し、ステップＳ６１２で生成したアクセストークンの署名を生成する。また、生成した署名を付加したアクセストークンを、端末１１１のアクセストークン要求モジュール３９１に送信してフローを終了する。表６は認証・認可サーバー秘密鍵管理モジュール３０６が管理する認証・認可サーバー秘密鍵情報を表す。
Figure 2019096076
ここではＥｕｒｏｐｅリージョンの認証・認可サーバー１５１について説明をしているため、認証・認可サーバー秘密鍵管理モジュール３０６が管理する秘密鍵情報も、Ｅｕｒｏｐｅリージョンの認証・認可サーバー１５１のものである。Ｊａｐａｎリージョンの認証・認可サーバー１６１においては、認証・認可サーバー秘密鍵管理モジュール３０６が管理する秘密鍵情報は、Ｊａｐａｎリージョンの認証・認可サーバー１６１のものとなる。
また以下はステップＳ６１３で送信されるアクセストークンの例である。アクセストークンはＪＷＴフォーマットで記述される。このように、アクセストークンの検証をリソースサーバーで行うためのアクセストークンを、署名付きアクセストークンと称する。なお、本実施例において署名付きアクセストークンを単にアクセストークンと称しているが、通常のアクセストークンと署名付きアクセストークンを分別する必要がある場合は、その旨を明記する。

{
"kid": "EuropeKey1",
"typ":"JWT",
"alg": "RS256"
}
{
"iss": "https://europe.authorization.example.com/",
"sub": "User001",
"aud": "https://europe.resource.example.com/",
"exp": 1508893210,
"iat": 1508889610,
"jti": "98765432109876543210987654321098765432109876543210",
"authz:scopes": [
"ScopeA",
"ScopeB"
]
}
上記のハッシュ値に認証・認可サーバー１５１の秘密鍵で署名したものを付加し、アクセストークン要求モジュール３９１に返却される。
ここではアクセストークンリクエストと共通する部分の説明は割愛し、アクセストークンに特徴的な部分について説明する。アクセストークンはＥｕｒｏｐｅリージョンの認証・認可サーバー１５１の秘密鍵で署名されるため、ｋｉｄはＥｕｒｏｐｅＫｅｙ１となっている。またアクセストークンの発行者ｉｓｓは認証・認可サーバー１５１を表す。アクセストークンの利用者ａｕｄはＥｕｒｏｐｅリージョンを表す情報になっていて、アクセストークンを利用可能なリージョンを制限する。ここではａｕｄはリソースサーバー１５２のＵＲＩを表しているが、リージョンを表す方式は前述の方式に限定されるものではなく、またリージョンを表す情報も複数持つ方式であってもよい。またａｕｔｈｚ：ｓｃｏｐｅｓは委譲された権限の範囲を表し、ここでは「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」が委譲されている。
ステップＳ６３０でアクセストークン発行モジュール３０４は、署名が不正である旨を端末１１１のアクセストークン要求モジュール３９１に送信し、アクセストークン発行を拒否してフローを終了する。ステップＳ６３１でアクセストークン発行モジュール３０４は、ＯＡｕｔｈオーナーが存在しない旨を端末１１１のアクセストークン要求モジュール３９１に送信し、アクセストークン発行を拒否してフローを終了する。ステップＳ６３２でアクセストークン発行モジュール３０４は、要求されたスコープが認可されていない旨を端末１１１のアクセストークン要求モジュール３９１に送信し、アクセストークン発行を拒否してフローを終了する。
図７は本実施の形態に係る、リソースサーバー１５２におけるリソースアクセスの処理フローである。本フローはリソースサーバー１５２のリソースアクセス処理モジュール３５１が、端末１１１のリソース要求モジュール３９３からのリソースアクセス要求を受信することで開始される。なお以下ではＥｕｒｏｐｅリージョンのリソースサーバー１５２のフローとして説明をしているが、Ｊａｐａｎリージョンのリソースサーバー１６２がリソースアクセス要求を受信した場合のリソースアクセス処理のフローも同様である。
ステップＳ７０１でリソースアクセス処理モジュール３５１は、本フローの冒頭で受信したアクセストークンの署名検証を行う。具体的には、アクセストークンのｋｉｄで示される認証・認可サーバーの公開鍵を、認証・認可サーバー公開鍵管理モジュール３５３から取得し、署名を検証する。表７は認証・認可サーバー公開鍵管理モジュール３５３が管理する認証・認可サーバー公開鍵テーブルの例である。
Figure 2019096076
ステップＳ７０２でリソースアクセス処理モジュール３５１は、ステップＳ７０１で署名が有効であるため正しいと判断されたか確認する。署名が正しかった場合はステップＳ７０３に遷移し、署名が正しくなかった場合はステップＳ７３０に遷移する。
ステップＳ７０３でリソースアクセス処理モジュール３５１は、リージョン記憶モジュール３５２から、リソースサーバー自身のリージョンを取得し、自身が所属するリージョンを解決する。ステップＳ７０４でリソースアクセス処理モジュール３５１は、本フローの冒頭で受信したリソースアクセス要求に含まれるアクセストークンから、アクセストークンを利用可能なリージョンを取得する。たとえばアクセストークンのａｕｄに 「https://europe.resource.example.com/」のように記載されていた場合を考える。このときＵＲＬに含まれる文字列から、このアクセストークンを利用可能なリージョンとしてＥｕｒｏｐｅリージョンが取得できる。また、アクセストークンのａｕｄに 「https://www.resource.example.com/」のように記載されていた場合を考える。このときＵＲＬに含まれる文字列から、このアクセストークンを利用可能なリージョンとしてすべてのリージョンを示す情報が取得できる。なおアクセストークンを利用可能なリージョンの取得の仕方は前述の方式に限定されるものではない。
ステップＳ７０５でリソースアクセス処理モジュール３５１は、ステップＳ７０３で取得したリソースサーバー自身のリージョンと、ステップＳ７０４で取得したアクセストークンを利用可能なリージョンを比較し、アクセストークンの利用可否を判断する。アクセストークンを利用可能であると判断された場合はステップＳ７０６に遷移し、アクセストークンを利用不可能であると判断された場合はステップＳ７３１に遷移する。たとえばリソースサーバー自身のリージョンがＥｕｒｏｐｅリージョンの場合を考える。ステップＳ７０４で取得できたアクセストークンを利用可能なリージョンがＥｕｒｏｐｅリージョンだった場合や、すべてのリージョンを表す情報だった場合、アクセストークンを利用可能と判断される。またステップＳ７０４で取得できたアクセストークンを利用可能なリージョンがＪａｐａｎリージョンで、Ｅｕｒｏｐｅリージョンが含まれない場合、アクセストークンは利用不可能と判断される。
ステップＳ７０６でリソースアクセス処理モジュール３５１は、端末１１１のリソース要求モジュール３９３から要求された処理に必要なスコープを解決する。ステップＳ７０７でリソースアクセス処理モジュール３５１は、本フローの冒頭で受信したアクセストークンに含まれるスコープを取得する。この値はアクセストークンのａｕｔｈｚ：ｓｃｏｐｅｓで示される値から取得できる。
ステップＳ７０８でリソースアクセス処理モジュール３５１は、ステップＳ７０６で必要と判断されたスコープと、ステップＳ７０７でトークンに含まれるスコープを比較し、権限の有無を判断する。権限ありと判断された場合はステップＳ７０９に遷移し、権限なしと判断された場合はステップＳ７３２に遷移する。たとえばステップＳ７０６で必要と判断されたスコープが「ＳｃｏｐｅＡ」で、ステップＳ７０７でトークンに含まれるスコープが「ＳｃｏｐｅＡ」および「ＳｃｏｐｅＢ」であれば、権限ありと判断される。
ステップＳ７０９でリソースアクセス処理モジュール３５１は、端末１１１のリソース要求モジュール３９３から要求された処理を実行し、結果を返してフローを終了する。ステップＳ７３０でリソースアクセス処理モジュール３５１は、署名が不正である旨を返し、リソースアクセスを拒否してフローを終了する。ステップＳ７３１でリソースアクセス処理モジュール３５１は、リージョンが不正である旨を返し、リソースアクセスを拒否してフローを終了する。すなわち、クライアントはリソース要求を送信した先にあるリージョンのリソースサーバーを利用することはできない。ステップＳ７３２でリソースアクセス処理モジュール３５１は、権限不足である旨を返し、リソースアクセスを拒否してフローを終了する。
本実施の形態によれば、アクセストークン検証の処理負荷は分散させつつ、ユーザーデータを受け入れるのは、ユーザーが主として居住する地域と対応するリージョンのみとすることができる。またユーザーデータを操作することのないアクセスであれば、クライアントと地理的に近いリソースサーバーにアクセスできるため、ネットワーク遅延低減も享受できる。
［実施例２］
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。リージョンを分割する単位は、地域、国、共同体など、何でもよいため、同一の国の中に複数のリージョンが存在し、法規制も共通である場合も考えられる。このようなリージョン同士の間では、一方のサーバーで発行したアクセストークンを、他方のサーバーで利用できるようにすることで、利便性が増すと考えられる。たとえばドイツのベルリンの認証・認可サーバーでユーザーが発行されたが、実際に利用されるのは同じくドイツのハンブルク近郊である場合などが考えられる。このような場合では、ベルリンリージョンの認証・認可サーバーで発行されたアクセストークンで、ハンブルグリージョンのリソースサーバーにおけるユーザーデータにアクセスできるのが好ましい。
図９は本実施の第２の形態に係る、認証・認可サーバー１５１のモジュール構成を示す図である。なお認証・認可サーバー１６１も認証・認可サーバー１５１と同様の構成を取ることができる。認証・認可サーバー１５１は本実施の第１の形態のモジュールに加え、追加リージョン決定モジュール３１３、リージョン対応管理モジュール３１４を持つ。追加リージョン決定モジュール３１３はリージョン対応管理モジュールで３１４に問い合わせ、リージョン決定モジュール３１０で決定されたリージョンに対応する追加リージョンを取得する。取得した追加リージョンを加え、アクセストークンを利用可能なリージョンを決定する。
図１０は本実施の第２の形態における、追加リージョンを含めてアクセストークンの利用可能リージョンを決定するフローである。本フローは本実施の第１の形態における、図６のステップＳ６１３およびステップＳ６１５のあとで、ステップＳ１００１の処理を行う。ステップＳ１００１で追加リージョン決定モジュール３１３は、ステップＳ６１３もしくはステップＳ６１５で決定したリージョンに対応するリージョンをリージョン対応管理モジュール３１４に問い合わせて取得する。また取得したリージョンを追加リージョンとする。表８はリージョン対応管理モジュール３１４が管理するリージョン対応関係テーブルの例である。
Figure 2019096076
表８のリージョン対応関係テーブルでは、ＥｕｒｏｐｅリージョンとＥｕｒｏｐｅ−２リージョンが同一法規制配下であるとして、あらかじめ対応関係が管理されているものとする。ただしリージョンの対応関係を結ぶ基準は法規制が同一であるか否かに限定されるものでなく、他の妥当な基準でリージョン対応関係を結び管理してもよい。
ここで、ステップＳ６１３もしくはステップＳ６１５で決定したリージョンがＥｕｒｏｐｅリージョンだった場合、追加リージョンとしてＥｕｒｏｐｅ−２リージョンを取得できる。ステップＳ１００２でリージョン決定モジュール３１０は、アクセストークンの利用可能リージョンに、ステップＳ１００１で取得した追加リージョンを追加する。リージョンを追加した新たな利用可能リージョンが決定すると、ステップＳ６２１に遷移する。
本実施の第２の形態によれば、リソースサーバーは、自身と異なるリージョンのＯＡｕｔｈオーナーのアクセストークンであっても、対応関係のあるリージョン間であればアクセストークンを受け入れることができるようになる。そのためたとえば、同一法規制配下のリージョン間ではアクセストークンの相互利用が可能となるため、利便性が向上する。
［実施例３］
次に、本発明を実施するための第３の形態について図面を用いて説明する。なお第１および第２の実施の形態の内で少なくとも何れか１つの実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。端末１１１からのアクセスがリージョン不正だった場合、リソースサーバーとしては、アクセスを拒否することで目的を達成できる。しかしクライアントは、アクセストークンの利用可能リージョンと異なるリージョンに意図的にアクセスしたのでなく、ＧｅｏＤＮＳの指定に従っただけである可能性もある。そのような場合は、端末１１１からのアクセスを、適切なリージョンにリダイレクトさせることで、利便性が向上すると考えられる。
図１１は本実施の第３の形態に係る、リソースサーバー１５２のモジュール構成を示す図である。なおリソースサーバー１６２もリソースサーバー１５２と同様の構成を取ることができる。リソースサーバー１５２は本実施の第１の形態のモジュールに加え、リダイレクトモジュール３５４およびリダイレクト先管理モジュール３５５を持つ。リダイレクトモジュール３５４はリダイレクト先管理モジュールで３５５に問い合わせ、リソースアクセス処理モジュール３５１がリージョン不正と判断したアクセスを適正リージョンの同一機能を持つリソースサーバーにリダイレクトさせる。
図１２は本実施の第３の形態に係る、リージョン不正に伴うリダイレクトを含む、リソースサーバー１５２のリソースアクセス処理フローである。本フローは本実施の第１の形態における、図７のステップＳ７０５でリージョン不正と判断された際に、フローを終了する代わりにステップＳ１２０１に遷移し処理を行う。
ステップＳ１２０１でリダイレクトモジュール３５４は、ステップＳ７０４で取得したアクセストークンの利用可能リージョンをもとに、リダイレクト先管理モジュール３５５からリダイレクト先ＵＲＬを取得する。表９はリダイレクト先管理モジュール３５５が管理する他リージョンリソースサーバー情報テーブルの例である。
Figure 2019096076
他リージョンリソースサーバー情報テーブルでは、リソースサーバー１５２と同じ機能を備え、リソースサーバー１５２と異なるリージョンに存在するリソースサーバーのＵＲＬをリダイレクト先として管理する。たとえばステップＳ７０４で取得したアクセストークンの利用可能リージョンが「Ｊａｐａｎ」リージョンだった場合、リダイレクト先は「http://japan.resource.example.com/」となる。なお、アクセストークンに含まれるリージョンが表９に存在しない場合、あらかじめ設定されているリダイレクト先を採用することとする。表９の場合「Default」のリダイレクト先が、クセストークンに含まれるリージョンが表９に存在しない場合のリダイレクト先ということになる。
なおステップＳ１２０１のリダイレクト先決定処理は、あらかじめ用意された他リージョンリソースサーバー情報テーブルを用いる方式に限定されず、アクセストークンのａｕｄで示されるリソースサーバーのＵＲＬを用いる方式や、その他の方式であってもよい。
ステップＳ１２０２でリダイレクトモジュール３５４は、ステップＳ１２０１で取得したリダイレクト先ＵＲＬをリソース要求モジュール３９３に返し、適正なリージョンへのリダイレクトを促しフローを終了する。リダイレクトモジュール３５４は、クライアントを別のリージョンに存在する別のリソースサービスへリダイレクトさせることになる。
本実施の第３の形態によれば、リソース要求モジュール３９３は、不適切なリージョンにアクセスしようとしてしまった場合でも、適切なリージョンのリソースサーバーのＵＲＬの通知を受けることができる。そのためＧｅｏＤＮＳなどの仕組みを用いたことで、ユーザーが存在しないリージョンのリソースサーバーにアクセスしてしまった場合でも、正しいリージョンのリソースサーバーにリダイレクトされ処理を続行できるため、利便性が向上する。
［その他の実施例］
実施例１乃至３のいずれの実施例における各フロー図におけるステップは、その実行順番に制限があるわけではなく適宜実行順番を変えられるものである。例えば、図７および12におけるアクセストークンの検証とリージョンの確認のタイミングは必ずしも実施例通りの順番である必要はない。アクセストークンの検証およびスコープの検証が終わった後に、リージョンの検証を行う形態でも良い。各実施例で重要なのはリージョンの検証であり、アクセストークンの検証およびスコープの検証と言った認可に関する各検証は条件の内の１つにしか過ぎず、必ずしもフローで示した通りである必要はなく、適宜変更可能である。
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
１１１ 端末
１５１ 認証・認可サーバー
１５２ リソースサーバー
３０４ アクセストークン発行モジュール
３１０ リージョン決定モジュール
３１３ 追加リージョン決定モジュール
３５１ リソースアクセス処理モジュール
３５４ リダイレクトモジュール
３９１ アクセストークン要求モジュール
３９３ リソース要求モジュール

Claims (10)

  1. クライアントを有する端末、リソースを有するリソースサーバー、および認可サーバーを少なくとも含むアクセス制御システムであって、
    前記認可サーバーは、
    アクセストークンの検証を前記リソースサーバーで行うための署名付きアクセストークンを発行する発行手段を有し、
    前記リソースサーバーは、
    前記クライアントから送信されるリソース要求および前記署名付きアクセストークンを受信した場合、前記署名付きアクセストークンの署名検証を行い、前記署名付きアクセストークンが有効であるかを判断する判断手段と、
    前記署名付きアクセストークンに含まれるリージョンと前記リソースサーバーのリージョンを比較し、前記リソースサーバーのリージョンが前記署名付きアクセストークンに含まれているかを確認する確認手段と、
    前記判断手段により有効であると判断され、かつ前記確認手段により含まれていると確認されたことに応じて、前記リソース要求に対する処理を実行する実行手段と、を有することを特徴とするアクセス制御システム。
  2. 前記実行手段は、前記確認手段により含まれていないと確認されたことに応じて、前記リソース要求に対する処理を実行せず、リージョンが不正である旨を前記クライアントへ返すことを特徴とする請求項１に記載のアクセス制御システム。
  3. 前記発行手段は、前記リソースのオーナーと前記クライアントが同一でない場合、ユーザーが認可操作により前記リソースへのアクセスを許可したことに応じて、前記認可操作を行ったユーザーが所属するリージョンを含む前記署名付きアクセストークンを発行することを特徴とする請求項１または２に記載のアクセス制御システム。
  4. 前記発行手段は、前記リソースのオーナーと前記クライアントが同一であり、かつ前記オーナーとユーザーが関連づいていない場合、すべてのリージョンを含む前記署名付きアクセストークンを発行することを特徴とする請求項１乃至３の何れか１項に記載のアクセス制御システム。
  5. 前記発行手段は、前記リソースのオーナーと前記クライアントが同一であり、かつ前記オーナーと特定のユーザーが関連づいている場合、前記特定のユーザーが所属するリージョンを含む前記署名付きアクセストークンを発行することを特徴とする請求項１乃至４の何れか１項に記載のアクセス制御システム。
  6. 前記認可サーバーは、
    特定のリージョンに対応する追加リージョンを記憶する記憶手段を有し、
    前記発行手段は、ユーザーが所属するリージョンに対応する前記追加リージョンを特定し、当該ユーザーが所属するリージョンおよび特定された前記追加リージョンの２つのリージョンを含む前記署名付きアクセストークンを発行することを特徴とする請求項１乃至５の何れか１項に記載のアクセス制御システム。
  7. 前記リソースサーバーは、
    前記リソースサーバーのリージョンが前記署名付きアクセストークンに含まれていないことが前記確認手段により確認されたことに応じて、前記署名付きアクセストークンを基に、前記署名付きアクセストークンで利用可能な別のリージョンに存在する別のリソースサーバーへ前記クライアントをリダイレクトさせるリダイレクト手段を有することを特徴とする請求項１乃至６の何れか１項に記載のアクセス制御システム。
  8. 前記確認手段は、前記署名付きアクセストークンに含まれるスコープと前記リソース要求が指定するスコープとを比較し、前記リソース要求が指定するスコープが前記署名付きアクセストークンに含まれているかを確認し、
    前記実行手段は、前記リソース要求が指定するスコープが前記署名付きアクセストークンに含まれていることが前記確認手段により確認されたことを条件に、前記リソース要求に対する処理を実行することを特徴とする請求項１乃至７の何れか１項に記載のアクセス制御システム。
  9. クライアントを有する端末、リソースを有するリソースサーバー、および認可サーバーを少なくとも含むアクセス制御システムで実行される制御方法あって、
    アクセストークンの検証をリソースサーバーで行うための署名付きアクセストークンを発行する発行ステップと、
    前記クライアントから送信されるリソース要求および前記署名付きアクセストークンを受信した場合、前記署名付きアクセストークンの署名検証を行い、前記署名付きアクセストークンが有効であるかを判断する判断ステップと、
    前記署名付きアクセストークンに含まれるリージョンと前記リソースサーバーのリージョンを比較し、前記リソースサーバーのリージョンが前記署名付きアクセストークンに含まれているかを確認する確認ステップと、
    前記判断ステップにおいて有効であると判断され、かつ前記確認ステップにおいて含まれていると確認されたことに応じて、前記リソース要求に対する処理を実行する実行ステップと、を含むことを特徴とする制御方法。
  10. クライアントを有する端末、リソースを有するリソースサーバー、および認可サーバーを少なくとも含むアクセス制御システムにおける前記リソースサーバーで実行される制御方法を実行するためのプログラムであって、
    クライアントから送信されるリソース要求および署名付きアクセストークンを受信した場合、前記署名付きアクセストークンの署名検証を行い、前記署名付きアクセストークンが有効であるかを判断する判断ステップと、
    前記署名付きアクセストークンに含まれるリージョンと前記リソースサーバーのリージョンを比較し、前記リソースサーバーのリージョンが前記署名付きアクセストークンに含まれているかを確認する確認ステップと、
    前記判断ステップにおいて有効であると判断され、かつ前記確認ステップにおいて含まれていると確認されたことに応じて、前記リソース要求に対する処理を実行する実行ステップと、を含むことを特徴とするプログラム。
JP2017225129A 2017-11-22 2017-11-22 アクセス制御システム、その制御方法およびプログラム Pending JP2019096076A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017225129A JP2019096076A (ja) 2017-11-22 2017-11-22 アクセス制御システム、その制御方法およびプログラム
US16/196,971 US10963554B2 (en) 2017-11-22 2018-11-20 Access control system, control method of access control system, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017225129A JP2019096076A (ja) 2017-11-22 2017-11-22 アクセス制御システム、その制御方法およびプログラム

Publications (1)

Publication Number Publication Date
JP2019096076A true JP2019096076A (ja) 2019-06-20

Family

ID=66532429

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017225129A Pending JP2019096076A (ja) 2017-11-22 2017-11-22 アクセス制御システム、その制御方法およびプログラム

Country Status (2)

Country Link
US (1) US10963554B2 (ja)
JP (1) JP2019096076A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019139520A (ja) * 2018-02-09 2019-08-22 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
JP2020053100A (ja) * 2019-12-27 2020-04-02 キヤノン株式会社 情報処理システムと、その制御方法とプログラム

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113158198B (zh) * 2020-01-22 2024-07-05 华为技术有限公司 访问控制方法、装置、终端设备和存储介质
US11757635B2 (en) * 2020-03-13 2023-09-12 Mavenir Networks, Inc. Client authentication and access token ownership validation
US11601285B2 (en) * 2020-06-24 2023-03-07 EMC IP Holding Company LLC Securely authorizing service level access to a backup system using a specialized access key
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
CN112511569B (zh) * 2021-02-07 2021-05-11 杭州筋斗腾云科技有限公司 网络资源访问请求的处理方法、系统及计算机设备
US11632362B1 (en) * 2021-04-14 2023-04-18 SHAYRE, Inc. Systems and methods for using JWTs for information security
CN113297563B (zh) * 2021-06-18 2023-01-24 海光信息技术股份有限公司 访问片上系统特权资源的方法、装置及片上系统
US11836361B2 (en) * 2021-08-25 2023-12-05 Nvidia Corporation Implementing compiler-based memory safety for a graphic processing unit
CN115189967A (zh) * 2022-09-07 2022-10-14 杭州海康威视数字技术股份有限公司 访问控制方法、装置、电子设备及机器可读存储介质
US20240171587A1 (en) * 2022-11-23 2024-05-23 Microsoft Technology Licensing, Llc Region-based authentication and access policies for services
CN118573385A (zh) * 2023-02-28 2024-08-30 华为技术有限公司 通信方法和通信装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020023123A1 (en) * 1999-07-26 2002-02-21 Justin P. Madison Geographic data locator
JP6198477B2 (ja) 2013-06-21 2017-09-20 キヤノン株式会社 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム
JP6335657B2 (ja) * 2014-05-30 2018-05-30 キヤノン株式会社 権限委譲システム、方法、認証サーバーシステム、およびプログラム
US9514324B1 (en) * 2014-06-20 2016-12-06 Amazon Technologies, Inc. Approaches for restricting access to data
US10306016B2 (en) * 2016-02-01 2019-05-28 General Electric Company System and method for scoped attributes
US10148668B2 (en) * 2017-01-25 2018-12-04 Ca, Inc. Geolocation-based authentication credentials

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019139520A (ja) * 2018-02-09 2019-08-22 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
JP2020053100A (ja) * 2019-12-27 2020-04-02 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
JP7043480B2 (ja) 2019-12-27 2022-03-29 キヤノン株式会社 情報処理システムと、その制御方法とプログラム

Also Published As

Publication number Publication date
US10963554B2 (en) 2021-03-30
US20190156008A1 (en) 2019-05-23

Similar Documents

Publication Publication Date Title
JP2019096076A (ja) アクセス制御システム、その制御方法およびプログラム
CN110138718B (zh) 信息处理系统及其控制方法
US8347403B2 (en) Single point authentication for web service policy definition
US9762568B2 (en) Consolidated authentication
US8881248B2 (en) Service provider access
JP6198477B2 (ja) 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム
US9021570B2 (en) System, control method therefor, service providing apparatus, relay apparatus and computer-readable medium
US10135831B2 (en) System and method for combining an access control system with a traffic management system
JP6124687B2 (ja) 画像形成装置、サーバー装置、情報処理方法及びプログラム
US20030226036A1 (en) Method and apparatus for single sign-on authentication
US20140230020A1 (en) Authorization server and client apparatus, server cooperative system, and token management method
US20130185784A1 (en) Authority delegate system, server system in authority delegate system, and control method for controlling authority delegate system
JP6806543B2 (ja) 権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法
US11444954B2 (en) Authentication/authorization server, client, service providing system, access management method, and medium
JP2017004301A (ja) 認証サーバーシステム、方法、プログラムおよび記憶媒体
US9916308B2 (en) Information processing system, document managing server, document managing method, and storage medium
US9077708B2 (en) Information processing system, control method for controlling the information processing system, and storage medium
JP2016115260A (ja) 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム
US9225713B2 (en) System, control method, and storage medium
JP2016057737A (ja) サービス提供システム及びこれに用いる管理サーバー及び管理方法
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
Baker OAuth2