(57)【要約】【課題】認証・認可に係る管理情報に変更が生じる場合においても、アクセストークンを用いた適正な認証・認可を行える仕組みを提供する。【解決手段】認証・認可に係る管理情報を変更する指示があった場合、アクセストークン発行部から発行されたアクセストークンであって当該変更により無効となるアクセストークンの残りの有効期限を取得し（Ｓ１１０９〜Ｓ１１１１）、当該取得された残りの有効期限が経過した後に、管理情報を変更する処理を行う（Ｓ１１１２）。【選択図】図１１
2018032085.tif 000002
【特許請求の範囲】
【請求項１】
認証・認可に係る情報を管理情報として管理する情報処理装置であって、
アクセストークンを発行する発行手段と、
前記管理情報を変更する指示があった場合、前記発行手段から発行されたアクセストークンであって当該変更により無効となるアクセストークンの残りの有効期限を取得する取得手段と、
前記取得手段で取得された残りの有効期限が経過した後に、前記管理情報を変更する処理を行う変更手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記取得手段は、前記変更により無効となるアクセストークンが複数ある場合、前記残りの有効期限の最大値を更に取得し、
前記変更手段は、前記最大値に係る残りの有効期限が経過した後に、前記管理情報を変更する処理を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記発行手段は、前記管理情報を変更する指示があった後であって前記取得手段で取得された残りの有効期限が経過する前に、前記変更により無効となるアクセストークンを発行する指示があった場合、当該アクセストークンの有効期限が前記取得手段で取得された残りの有効期限までに終了する場合に、当該アクセストークンを発行することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記発行手段は、アクセストークンを発行する指示があった場合、クライアントから利用するサービスのリージョン情報を取得し、当該リージョン情報に係るリージョンに応じてアクセストークンを発行することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記発行手段は、前記リージョン情報に係るリージョンが当該情報処理装置と同一のリージョンでない場合、署名付きのアクセストークンを発行することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記発行手段は、前記リージョン情報に係るリージョンが当該情報処理装置と同一のリージョンである場合、署名なしのアクセストークンを発行することを特徴とする請求項４に記載の情報処理装置。
【請求項７】
前記管理情報を緊急に変更する指示があった場合、当該変更により無効となるアクセストークンが利用するサービスを提供する他の情報処理装置に対して、当該アクセストークンの無効依頼を送信する送信手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
前記変更手段は、前記他の情報処理装置から前記無効依頼に基づく無効処理を行った旨の通知を受信した場合に、前記管理情報を変更する処理を行うことを特徴とする請求項７に記載の情報処理装置。
【請求項９】
認証・認可に係る情報を管理情報として管理する情報処理装置の情報処理方法であって、
アクセストークンを発行する発行ステップと、
前記管理情報を変更する指示があった場合、前記発行ステップで発行されたアクセストークンであって当該変更により無効となるアクセストークンの残りの有効期限を取得する取得ステップと、
前記取得ステップで取得された残りの有効期限が経過した後に、前記管理情報を変更する処理を行う変更ステップと
を有することを特徴とする情報処理方法。
【請求項１０】
請求項１乃至８のいずれか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証・認可に係る情報を管理情報として管理する情報処理装置及びその情報処理方法、並びに、当該情報処理装置としてコンピュータを機能させるためのプログラムに関するものである。
【背景技術】
【０００２】
現在、ほとんどのネットワーク上のＷｅｂサービスでは、利用者がＷｅｂサービスの利用を認められているかどうかの認証・認可が行われている。そして、Ｗｅｂサービスが多様化し、複数のＷｅｂサービスが互いに連携を行うようになるにつれて、Ｗｅｂサービスを提供するリソースサーバーと認証・認可を行う認証・認可サーバーとが別々のサーバーとして構成されるようになってきた。このような構成では、認証・認可サーバーとリソースサーバーとが互いに情報を授受することで連携している。この際、認証・認可サーバーは、認可情報を含むアクセストークンを発行し、クライアントは、このアクセストークンを利用してリソースサーバーからサービスの提供を受ける。このような認可情報の授受に関する仕様の１つとしては、例えば、ＯＡｕｔｈ等がある。
【０００３】
この際、アクセストークンの正当性を検証するため、リソースサーバーは、認証・認可サーバーに対してアクセストークンの検証を依頼することができる。また、認証・認可サーバーの管理情報に変更が生じた場合には、アクセストークンの認可情報にも影響が及ぶことがある。ここで、アクセストークンの認可情報に影響が及んだ場合の対処方法としては、例えば、特許文献１に記載の方法がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−１３４８８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
近年、認証・認可サーバーとＷｅｂサービスを提供するリソースサーバーとの分離により、例えば国を跨ぐようなネットワーク的に遠いサーバー同士で連携する場合も出てきた。このような場合、ネットワーク的に遠い認証・認可サーバーとリソースサーバーとが密に連携してしまうと、処理のパフォーマンスが著しく低下してしまうこともある。
【０００６】
そこで、リソースサーバーが認証・認可サーバーにアクセストークンの検証を依頼せずにアクセストークンの正当性を確認することができるように、認証・認可サーバーが署名付きのアクセストークンを発行することが考えられる。なお、署名付きのトークンに関する仕様としては、例えば、ＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）等がある。これにより、処理のパフォーマンスの低下を防ぎながらアクセストークンの検証が行えるようになる。
【０００７】
しかしながら、認証・認可サーバーにアクセストークンの検証を依頼しなくなったことにより、アクセストークンを発行した後に認証・認可サーバーの管理情報に変更が生じた場合、当該アクセストークンが無効になったことを検知することができなくなる。その結果、認証・認可サーバーが管理する管理情報である認可情報とアクセストークンの認可情報との間で差異が生じ、適正な認証・認可が行えないという問題がある。
【０００８】
本発明は、このような問題点に鑑みてなされたものであり、認証・認可に係る管理情報に変更が生じる場合においても、アクセストークンを用いた適正な認証・認可を行える仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の情報処理装置は、認証・認可に係る情報を管理情報として管理する情報処理装置であって、アクセストークンを発行する発行手段と、前記管理情報を変更する指示があった場合、前記発行手段から発行されたアクセストークンであって当該変更により無効となるアクセストークンの残りの有効期限を取得する取得手段と、前記取得手段で取得された残りの有効期限が経過した後に、前記管理情報を変更する処理を行う変更手段とを有する。
また、本発明は、上述した情報処理装置の情報処理方法、及び、上述した情報処理装置の各手段としてコンピュータを機能させるためのプログラムを含む。
【発明の効果】
【００１０】
本発明によれば、認証・認可に係る管理情報に変更が生じる場合においても、アクセストークンを用いた適正な認証・認可を行うことができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係る情報処理装置のハードウェア構成の一例を示す図である。
【図２】本発明の実施形態に係る情報処理システムの概略構成の一例を示す図である。
【図３】一般的な情報処理システムにおけるアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。
【図４】一般的な情報処理システムにおける署名付きアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。
【図５−１】一般的な情報処理システムにおいて管理情報が変更（削除も含む）された場合の処理手順の一例を示すシーケンス図である。
【図５−２】一般的な情報処理システムにおいて管理情報が変更（削除も含む）された場合の処理手順の一例を示すシーケンス図である。
【図６】本発明の実施形態に係る認証・認可サーバー（情報処理装置）の機能構成の一例を示す図である。
【図７】図６のテナント管理部で管理するテナント情報、図６のユーザー管理部で管理するユーザー情報、図６のライセンス管理部で管理するライセンス情報、及び、図６のロール管理部で管理するロール情報の関係を示す図である。
【図８】本発明の実施形態を示し、アクセストークンを説明するための図である。
【図９】本発明の実施形態に係る認証・認可サーバー（情報処理装置）において、発行した署名付きアクセストークンが有効な間にユーザーの削除指示を受けた場合の処理例を示す概念図である。
【図１０】本発明の実施形態に係る認証・認可サーバー（情報処理装置）において、図９によってユーザーＡの削除予約がされている間にアクセストークンの発行指示を受けた場合の処理例を示す概念図である。
【図１１】本発明の実施形態に係る認証・認可サーバー（情報処理装置）において、管理情報の変更処理に係る処理手順の一例を示すフローチャートである。
【図１２】本発明の実施形態に係る認証・認可サーバー（情報処理装置）において、アクセストークンの発行処理に係る処理手順の一例を示すフローチャートである。
【図１３】本発明の実施形態に係る情報処理システムの他の概略構成の一例を示す図である。
【図１４】本発明の実施形態に係る認証・認可サーバー（情報処理装置）において、署名付きアクセストークンと署名なしアクセストークンとを切り替えて発行する際の処理手順の一例を示すフローチャートである。
【図１５】本発明の実施形態に係る情報処理システムにおける署名付きアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。
【図１６】本発明の実施形態に係る情報処理システムにおける管理情報の変更処理及び署名付きアクセストークンの無効処理に係る処理手順の一例を示すフローチャートである。
【図１７】本発明の実施形態に係るリソースサーバー（情報処理装置）の機能構成の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下に、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。
【００１３】
図１は、本発明の実施形態に係る情報処理装置１００のハードウェア構成の一例を示す図である。
【００１４】
情報処理装置１００は、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、ビデオインタフェース１０４、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下、「Ｉ／Ｏ」と記載する）インタフェース１０５、通信インタフェース１０６、及び、システムバス１０７を有している。この際、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、ビデオインタフェース１０４、Ｉ／Ｏインタフェース１０５、及び、通信インタフェース１０６は、システムバス１０７を介して、互いに電気的に接続されている。また、図１に示す記憶装置１０３には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、及び、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３が適用できる旨が示されている。また、情報処理装置１００は、ディスプレイ装置１１４、キーボード１１５、及び、ポインティングデバイス１１６を有している。
【００１５】
ＣＰＵ１０１は、システムバス１０７を介して各ハードウェア構成部を制御することにより、情報処理装置１００の動作を統括的に制御する中央処理装置である。さらに、ＣＰＵ１０１は、データの計算や加工等の、各種の処理を行う。
【００１６】
メモリ１０２は、各種のデータや各種のプログラムを記憶する。このメモリ１０２は、例えば、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等から構成されている。
【００１７】
記憶装置１０３は、記憶されたデータの書き込み／読み出しを行う装置である。なお、図１の記憶装置１０３には、ＨＤＤ１１１、ＤＶＤ−ＲＯＭドライブ１１２、及び、ＳＳＤ１１３が適用できる例が示されているが、本実施形態においてはこの態様に限定されるものではない。例えば、記憶装置１０３として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブ等を適用する態様も、本実施形態に含まれるものとする。
【００１８】
また、本実施形態に係るプログラムは、記憶装置１０３から読み込まれ、メモリ１０２に格納した上で、ＣＰＵ１０１によって実行されるものとする。なお、本実施形態では、記憶装置１０３からプログラムを読み込む構成としているが、例えば不図示のＲＯＭから読み込んだり、通信インタフェース１０６を介して外部装置Ｇから読み込んだりする構成としてもよい。
【００１９】
ビデオインタフェース１０４は、ＣＰＵ１０１の制御に基づいて、ディスプレイ装置１１４に表示出力を行う。ディスプレイ装置１１４としては、例えばＣＲＴや液晶等の方式を用いた装置を適用することができる。
【００２０】
Ｉ／Ｏインタフェース１０５には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより、情報処理装置１００（具体的にはＣＰＵ１０１）に対する動作指令等を行う。ポインティングデバイス１１６は、例えば、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行うものである。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもあり、この場合には、ディスプレイ装置１１４は、出力装置と入力装置を兼ねることになる。
【００２１】
通信インタフェース１０６は、コンピュータネットワーク１１７を通して、外部装置Ｇとの通信を行う。この際、接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。
【００２２】
図２は、本発明の実施形態に係る情報処理システム２００の概略構成の一例を示す図である。
【００２３】
情報処理システム２００は、図２に示すように、認証・認可サーバー２０１、リソースサーバー２０２及び２０４、クライアント２０３、インターネット２１０、並びに、コンピュータネットワーク２１１、２１２及び２１３を有して構成されている。
【００２４】
具体的に、インターネット２１０には、コンピュータネットワーク２１１、２１２及び２１３が接続されている。そして、コンピュータネットワーク２１１には、認証・認可サーバー２０１、及び、リソースサーバー２０２が接続されている。また、コンピュータネットワーク２１２にはクライアント２０３が接続され、コンピュータネットワーク２１３にはリソースサーバー２０４が接続されている。
【００２５】
ここで、本実施形態においては、認証・認可サーバー２０１、リソースサーバー２０２、クライアント２０３、及び、リソースサーバー２０４は、いずれも、図１に示す情報処理装置１００のハードウェア構成を有して構成されているものとする。ただし、各装置のハードウェア構成は、図１に示す形態に限定されるものではなく、必要に応じて、例えばディスプレイ装置１１４を備えていない形態や、他の機能を備えている形態であってもよい。また、サーバーは、単体のコンピュータに限らず、ラックマウント型のシステムであってもよい。
【００２６】
認証・認可サーバー２０１は、認証・認可に係る情報を管理情報として管理する情報処理装置１００であって、認可情報を含むアクセストークンを発行等する処理を行う。
【００２７】
リソースサーバー２０２及びリソースサーバー２０４は、Ｗｅｂサービス（以下、単に「サービス」と記載する）を提供する情報処理装置１００である。
【００２８】
図２において、リソースサーバー２０２は、認証・認可サーバー２０１と同じコンピュータネットワーク２１１に接続されており、認証・認可サーバー２０１とはネットワーク上近い位置に存在している。一方、リソースサーバー２０４は、インターネット２１０を跨いだコンピュータネットワーク２１３に接続されており、認証・認可サーバー２０１とはネットワーク上遠い位置に存在している。即ち、リソースサーバー２０２とリソースサーバー２０４とは、同様の機能を有しているが、認証・認可サーバー２０１とのネットワーク上の距離が異なることを示している。
【００２９】
クライアント２０３は、認証・認可サーバー２０１からアクセストークンを取得し、取得したアクセストークンを使って、リソースサーバー２０２やリソースサーバー２０４からサービスの提供を受ける情報処理装置１００である。なお、クライアント２０３は、図２に示すように、コンピュータネットワーク２１２接続されている形態に限らず、例えば、コンピュータネットワーク２１１やコンピュータネットワーク２１３に接続されている形態であってもよい。
【００３０】
以下に、図３〜図５−２を用いて、一般的な情報処理システムにおけるアクセストークン発行後の処理の流れについて説明する。
【００３１】
図３は、一般的な情報処理システムにおけるアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。この図３では、便宜的に、図２に示す認証・認可サーバー２０１、リソースサーバー２０２、及び、クライアント２０３との間の連携を図示している。
【００３２】
まず、ステップＳ３０１において、クライアント２０３は、認証・認可サーバー２０１に対して認証情報或いは認可コードを渡してアクセストークンの発行を要求し、認証・認可サーバー２０１からアクセストークンを取得する。この際、認証情報か認可コードかは、オーナーの違いによって異なる。クライアント２０３が処理を実施するオーナーである場合にはクライアント２０３自体が認証を行って認証情報を渡し、クライアント２０３が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡すことになる。
【００３３】
続いて、ステップＳ３０２において、クライアント２０３は、認証・認可サーバー２０１から取得したアクセストークンを使って、リソースサーバー２０２に対してサービスの提供を要求する。
【００３４】
続いて、ステップＳ３０３において、リソースサーバー２０２は、クライアント２０３から受け取ったアクセストークンが適正（有効）か否かについて、認証・認可サーバー２０１に検証するように要求する。
【００３５】
続いて、ステップＳ３０４において、認証・認可サーバー２０１は、ステップＳ３０３の要求に基づくアクセストークンの検証を行う。そして、認証・認可サーバー２０１は、当該検証結果をリソースサーバー２０２に送信する。
【００３６】
認証・認可サーバー２０１から送信された検証結果が、アクセストークンが適正（有効）であることを示す場合には、続いて、ステップＳ３０５において、リソースサーバー２０２は、サービスを提供するための処理を実行する。そして、リソースサーバー２０２は、当該処理結果をクライアント２０３に送信する。
【００３７】
なお、認証・認可サーバー２０１から送信された検証結果が、アクセストークンが不適正である（有効でない）ことを示す場合には、リソースサーバー２０２は、ステップＳ３０５の処理を行わずに、エラーの情報をクライアント２０３に送信する。
【００３８】
図２に示すように、認証・認可サーバー２０１とリソースサーバー２０２とは、ネットワーク上近い位置に存在している。そのため、図３のステップＳ３０３において、リソースサーバー２０２から認証・認可サーバー２０１にアクセストークンの検証を依頼しても、処理のパフォーマンスはほとんど低下しない。
【００３９】
図４は、一般的な情報処理システムにおける署名付きアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。この図４では、便宜的に、図２に示す認証・認可サーバー２０１、クライアント２０３、及び、リソースサーバー２０４との間の連携を図示している。
【００４０】
まず、ステップＳ４０１において、クライアント２０３は、認証・認可サーバー２０１に対して認証情報或いは認可コードを渡して署名付きアクセストークンの発行を要求し、認証・認可サーバー２０１から署名付きアクセストークンを取得する。
【００４１】
続いて、ステップＳ４０２において、クライアント２０３は、認証・認可サーバー２０１から取得した署名付きアクセストークンを使って、リソースサーバー２０４に対してサービスの提供を要求する。
【００４２】
続いて、ステップＳ４０３において、リソースサーバー２０４は、受け取った署名を元にしてアクセストークンが適正（有効）か否かを検証する。ここで、リソースサーバー２０４は、認証・認可サーバー２０１の署名を認証する証明書を保持しており、この証明書で署名を確認することにより、認証・認可サーバー２０１で発行された適正（有効）なアクセストークンであるか否かを確認することができる。
【００４３】
続いて、ステップＳ４０４において、リソースサーバー２０４は、ステップＳ４０３の検証の結果、アクセストークンが適正（有効）である場合には、サービスを提供するための処理を実行する。そして、リソースサーバー２０４は、当該処理結果をクライアント２０３に送信する。
【００４４】
なお、ステップＳ４０３の検証の結果、アクセストークンが不適正である（有効でない）場合には、リソースサーバー２０４は、ステップＳ４０４の処理を行わずに、エラーの情報をクライアント２０３に送信する。
【００４５】
図２に示すように、認証・認可サーバー２０１とリソースサーバー２０４とは、ネットワーク上遠い位置に存在している。そのため、図３のステップＳ３０３に示すように認証・認可サーバー２０１にアクセストークンの検証を依頼すると、処理のパフォーマンスが低下してしまう。しかしながら、図４の場合には、ステップＳ４０３に示すようにリソースサーバー２０４内で検証を行うことにより、処理のパフォーマンスの低下を防ぐことができる。
【００４６】
図５−１及び図５−２は、一般的な情報処理システムにおいて管理情報が変更（削除も含む）された場合の処理手順の一例を示すシーケンス図である。
【００４７】
まず、図５−１の説明を行う。具体的に、図５−１は、図３に示す情報処理システムに対応している。
【００４８】
図５−１のステップＳ５０１において、クライアント２０３は、図３のステップＳ３０１と同様に、認証・認可サーバー２０１に対してアクセストークンの発行を要求し、認証・認可サーバー２０１からアクセストークンを取得する。
【００４９】
続いて、ステップＳ５０２において、認証・認可サーバー２０１は、入力装置からの入力情報等に基づいて、管理情報の変更（削除も含む）を行う。なお、このステップＳ５０２では、ステップＳ５０１で発行したアクセストークンが無効となるような管理情報の変更が行われるものとする。
【００５０】
続いて、ステップＳ５０３において、クライアント２０３は、認証・認可サーバー２０１から取得したアクセストークンを使って、リソースサーバー２０２に対してサービスの提供を要求する。
【００５１】
続いて、ステップＳ５０４において、リソースサーバー２０２は、クライアント２０３から受け取ったアクセストークンが適正（有効）か否かについて、認証・認可サーバー２０１に検証するように要求する。
【００５２】
続いて、ステップＳ５０５において、認証・認可サーバー２０１は、ステップＳ５０４の要求に基づくアクセストークンの検証を行う。そして、認証・認可サーバー２０１は、ステップＳ５０２において当該アクセストークンが無効となるような管理情報の変更が行われているため、リソースサーバー２０２に対して検証結果がエラーの情報を送信する。
【００５３】
そして、リソースサーバー２０２は、認証・認可サーバー２０１から検証結果がエラーの情報を受信すると、サービスを提供するための処理を行わずに、クライアント２０３に対して検証結果がエラーの情報を送信する。
【００５４】
図５−１のステップＳ５０５における認証・認可サーバー２０１の検証では、単にアクセストークンを発行したか否かだけではなく、その時の認証・認可サーバー２０１の管理情報に従って有効か否かを検証する。そのため、アクセストークンの発行後に管理情報の変更が行われたとしても、図３のステップＳ３０５におけるサービスを提供するための処理が実施される前にアクセストークンが有効であるか否かを再検証することが可能である。なお、認証・認可サーバー２０１の管理情報としては、例えば、後述するユーザー情報や、ロール情報、ライセンス情報等が挙げられる。
【００５５】
次に、図５−２の説明を行う。具体的に、図５−２は、図４に示す情報処理システムに対応している。
【００５６】
まず、ステップＳ５１１において、クライアント２０３は、図４のステップＳ４０１と同様に、認証・認可サーバー２０１に対して署名付きアクセストークンの発行を要求し、認証・認可サーバー２０１から署名付きアクセストークンを取得する。
【００５７】
続いて、ステップＳ５１２において、認証・認可サーバー２０１は、入力装置からの入力情報等に基づいて、管理情報の変更（削除も含む）を行う。なお、このステップＳ５１２では、図５−１のステップＳ５０２と同様に、ステップＳ５１１で発行した署名付きアクセストークンが無効となるような管理情報の変更が行われるものとする。
【００５８】
続いて、ステップＳ５１３において、クライアント２０３は、認証・認可サーバー２０１から取得した署名付きアクセストークンを使って、リソースサーバー２０４に対してサービスの提供を要求する。
【００５９】
続いて、ステップＳ５１４において、リソースサーバー２０４は、図４のステップＳ４０３と同様に、受け取った署名を元にしてアクセストークンが適正（有効）か否かを検証する。ここでは、リソースサーバー２０４は、ステップＳ５１２で当該アクセストークンが無効となるような管理情報の変更が行われたことを検知できないため、当該アクセストークンが適正（有効）であると判定することになる。
【００６０】
その後、ステップＳ５１５において、リソースサーバー２０４は、エラーとせずに、サービスを提供するための処理を実行し、当該処理結果をクライアント２０３に送信することになる。
【００６１】
このように、図５−２のステップＳ５１３におけるリソースサーバー２０４での検証では、本来無効となるべきアクセストークンが有効なまま扱われることになる。この図５−２の署名付きアクセストークンの検証では、認証・認可サーバー２０１にアクセストークンの検証を要求しないことで処理のパフォーマンス低下を防止することはできるが、アクセストークン発行後の管理情報の変更を検知できないという課題がある。
【００６２】
この課題は、重大な問題を引き起こすことになる。例えば、削除したはずのユーザーについて処理が行われていたりすると、アクセスログに矛盾が生じて履歴の検証ができなくなる問題を引き起こす。この際、アクセスログが課金情報に関係している場合には、より深刻な影響をもたらす。また、ライセンス数の上限を管理しているような場合、或るユーザーでアクセストークンを発行した直後にそのユーザーを削除し、その後、別のユーザーを新たに追加してアクセストークンを発行すれば、ライセンスの上限を一時的に回避することができてしまう。
【００６３】
そこで、図６以降に、本発明の実施形態における上述した問題の解決方法について説明する。
【００６４】
図６は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１の機能構成の一例を示す図である。認証・認可サーバー２０１は、図６に示すように、テナント管理部６０１、ユーザー管理部６０２、ライセンス管理部６０３、ロール管理部６０４、アクセストークン発行部６０５、発行済みアクセストークン管理部６０６、アクセストークン検証部６０７、予約情報管理部６０８、予約情報実行部６０９、及び、リソースサーバー情報管理部６１０の各機能構成を有して構成されている。
【００６５】
この図６に示す各機能構成部６０１〜６１０は、例えば、図１に示す情報処理装置１００のハードウェア構成を有する認証・認可サーバー２０１のＣＰＵ１０１が記憶装置１０３に記憶されているプログラムを実行することにより、実現される。
【００６６】
テナント管理部６０１は、テナント情報の管理を行う。ユーザー管理部６０２は、ユーザー情報の管理を行う。ライセンス管理部６０３は、ライセンス情報の管理を行う。ロール管理部６０４は、ロール情報の管理を行う。
【００６７】
アクセストークン発行部６０５は、署名付きアクセストークンの発行、及び、署名なしアクセストークンの発行を行う。発行済みアクセストークン管理部６０６は、アクセストークン発行部６０５で発行されたアクセストークンの情報を管理する。アクセストークン検証部６０７は、アクセストークン発行部６０５で発行された署名なしアクセストークンが有効か否かを検証する。なお、署名付きアクセストークンの検証は、リソースサーバーにおいて、後述する図１７のアクセストークン検証部１７０２で行われる。
【００６８】
予約情報管理部６０８は、後述する図９に示す管理情報の変更スケジュール情報を予約情報として管理する。予約情報実行部６０９は、予約情報管理部６０８で管理されている予約情報を実行する。
【００６９】
リソースサーバー情報管理部６１０は、認証・認可サーバー２０１と連携するリソースサーバーに関する情報を管理する。
【００７０】
ここで、本実施形態においては、認証・認可サーバー２０１の管理情報とは、認証・認可サーバー２０１で管理している情報（ユーザー情報、ライセンス情報、ロール情報等）の全体を示すものとする。このため、認証・認可サーバー２０１の管理情報の変更には、例えば、ロール情報等の変更のみならず当該ロール情報等の削除も含まれることになる。また、本実施形態においては、認証・認可サーバー２０１の管理情報の変更には、当該管理情報の削除も含まれるものとする。
【００７１】
図７は、図６のテナント管理部６０１で管理するテナント情報、図６のユーザー管理部６０２で管理するユーザー情報、図６のライセンス管理部６０３で管理するライセンス情報、及び、図６のロール管理部６０４で管理するロール情報の関係を示す図である。
【００７２】
テナント７０１は、サービスを提供する単位であり、顧客やグループごとに作成される環境である。このテナント７０１には、複数のユーザー７０２を登録することができる。
【００７３】
ライセンス７０３は、テナント７０１に設定することができる権限である。図７に示す例では、「ＰｒｉｎｔＳｅｒｖｉｃｅ」のライセンス７０３がテナント７０１に設定されており、テナント７０１の顧客或いはグループ内のユーザー７０２が印刷サービスを利用できることを示す。
【００７４】
ロール７０４は、ユーザー７０２に設定することができる役割であり、ライセンス７０３の情報に基づいてテナント７０１に付与される。図７に示す例では、ライセンス７０３の「ａｓｓｏｃｉａｔｅｄＲｏｌｅｓ」に定義されている「ＰｒｉｎｔＡｄｍｉｎ」、「ＰｒｉｎｔＵｓｅｒ」がテナント７０１でユーザー７０２に付与できるロールとなる。このロール７０４は、ＰｒｉｎｔＵｓｅｒロールを示しており、テナント７０１に設定されたライセンス７０３が提供する印刷サービスをユーザー７０２が利用できるように設定していることを意味する。
【００７５】
なお、ライセンス７０３には権利数があり、テナント７０１内で利用するユーザー７０２を制限することもできる。また、ロール７０４の「ｐｅｒｍｉｓｓｉｏｎＩｄｓ」は、ロール７０４の権限を定義したものであり、アクセストークンの権限と照らし合わせる際に利用される。また、この「ｐｅｒｍｉｓｓｉｏｎＩｄｓ」には、複数の権限を設定することもできる。
【００７６】
図８は、本発明の実施形態を示し、アクセストークンを説明するための図である。この図８を用いて、アクセストークン８０１と、図７に示すロール７０４、及び、スコープ８０２の関係について説明する。
【００７７】
アクセストークン８０１には、当該アクセストークン８０１をユニークに識別するための情報等が格納されているが、その他にもスコープ８０２を保持している。
【００７８】
スコープ８０２は、アクセストークン８０１によって認可される権限の範囲を示している。図８に示す例では、ＰｒｉｎｔＵｓｅｒロールを持つユーザーによって発行されたものであり、印刷サービスの処理を行うことができることを示している。また、スコープ８０２の「ｐｅｒｍｉｓｓｉｏｎ」は、図７に記載のロール７０４の「ｐｅｒｍｉｓｓｉｏｎＩｄｓ」に対応している。
【００７９】
図９は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１において、発行した署名付きアクセストークンが有効な間にユーザーの削除指示を受けた場合の処理例を示す概念図である。
【００８０】
図９には、処理の時間軸９００が示されている。アクセストークン９０１は、ユーザーＡがオーナーの署名付きアクセストークンであり、横の長さはアクセストークン９０１の有効期限を表している。
【００８１】
ここで、認証・認可サーバー２０１において、ユーザーＢの削除指示９０２を受けた場合、ユーザーＢは、発行済みの署名付きアクセストークン９０１と依存関係が存在しないため、削除が可能である。一方、ユーザーＡの削除指示９０３を受けた場合には、ユーザーＡがオーナーの署名付きアクセストークン９０１と依存関係がある。そのため、ユーザーＡを削除してしまうと、認証・認可サーバー２０１が管理する管理情報である認可情報と署名付きアクセストークン９０１の認可情報との間に差異が発生してしまう。その結果、図５−２で説明した問題が発生することになる。
【００８２】
図５−２に示すシステムの場合、署名付きアクセストークンは、認証・認可サーバー２０１が発行してクライアント２０３に渡した後は認証・認可サーバー２０１が制御することができない。そのため、図９に示す例の場合、認証・認可サーバー２０１で対応できる１つの解決方法としては、ユーザーＡを削除しないようにすることが考えられる。しかしながら、ユーザーＡを削除できないとすると、ユーザーＡの削除指示９０３を行ったシステム管理者等の利用者は、署名付きアクセストークン９０１の有効期間が終わるまで当該削除指示９０３の操作を待たなければならない。さらに、この待っている間に、ユーザーＡの別の署名付きアクセストークンが発行されると、利用者は、さらに待たなければならなくなり、利便性が損なわれる。
【００８３】
そこで、本実施形態に係る認証・認可サーバー２０１では、ユーザーＡの削除指示９０３を受けた場合、署名付きアクセストークン９０１の有効期限が経過した後にユーザーＡを削除すべく削除予約９０４を行うことにより、利便性を確保する。この場合、ユーザーＡの削除指示９０３があった時点から、管理情報からユーザーＡが削除されるまでがユーザーＡの削除予約中期間となる。この削除予約９０４を行うにあたっては他の制御も必要となる。
【００８４】
図１０は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１において、図９によってユーザーＡの削除予約９０４がされている間にアクセストークンの発行指示を受けた場合の処理例を示す概念図である。この図１０に示すユーザーＡの削除予約中期間は、図９に示すユーザーＡの削除予約中期間に相当する。このため、図１０に示すユーザーＡの削除予約中期間における左端の始点は、図９に示すユーザーＡの削除指示９０３があった時点であり、また、その右端の終点は、管理情報からユーザーＡが削除される時点である。
【００８５】
この図１０で発行するアクセストークンは、署名付き／署名なしの両方のアクセストークンが対象となる。アクセストークン発行指示１００１によってユーザーＡをオーナーとするアクセストークン１００２を発行してしまうと、アクセストークン１００２の有効期限がユーザーＡの削除後まで続いてしまうため、その発行を禁止する必要がある。一方、ユーザーＣをオーナーとするアクセストークン１００３は、ユーザーＡの削除予約９０４とは無関係であるため、通常通り、その発行が可能である。
【００８６】
また、ユーザーＡをオーナーとするアクセストークン１００２であっても、その有効期限がユーザーＡの削除前であればその発行は可能となる。即ち、認証・認可サーバー２０１（具体的にアクセストークン発行部６０５）は、ユーザーＡの削除予約中期間に、当該ユーザーＡの削除により無効となるアクセストークン１００２の発行指示１００１があった場合、当該アクセストークン１００２の有効期限が署名付きアクセストークン９０１の残りの有効期限までに終了する場合に、当該アクセストークン１００２を発行する。
【００８７】
なお、以上の制御は、リフレッシュトークンによるアクセストークンの再発行指示があった場合も同じである。
【００８８】
次に、図９及び図１０の概念図で示した内容について、その処理に関するフローチャートの一例を図１１及び図１２を用いて説明する。
【００８９】
図１１は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１において、管理情報の変更処理に係る処理手順の一例を示すフローチャートである。具体的に、図１１は、管理情報の変更として、認証・認可サーバー２０１で管理する管理情報の一種であるロールの変更・削除を行う場合を示している。
【００９０】
なお、図９では、ユーザーの削除を行う例について説明したが、図７及び図８で説明したように、ロール７０４やライセンス７０３の変更等もアクセストークン８０１の認可情報に影響を及ぼす。そのため、発行済みアクセストークンの認可情報に影響があるか否かを判断した上で、必要に応じてロールの変更・削除のタイミングを遅らせることになる。この際、ロールの変更・削除は、例えば、認証・認可サーバー２０１でテナントを管理する管理者等が変更・削除操作を行うことにより、認証・認可サーバー２０１に指示されるものとする。
【００９１】
ロールの変更・削除指示があった場合、まず、ステップＳ１１０１において、発行済みアクセストークン管理部６０６は、該当するユーザーで発行した有効期限内の署名付きアクセストークンを取得する。
【００９２】
続いて、ステップＳ１１０２において、発行済みアクセストークン管理部６０６は、ステップＳ１１０１で取得した署名付きアクセストークンの数を設定するとともに、署名付きアクセストークンを１つずつ処理対象として参照する。
【００９３】
続いて、ステップＳ１１０３において、発行済みアクセストークン管理部６０６は、処理対象の署名付きアクセストークンのスコープ８０２の情報を取得する。
【００９４】
続いて、ステップＳ１１０４において、発行済みアクセストークン管理部６０６は、ステップＳ１１０３で取得したスコープ８０２の情報に含まれるパーミッションに、削除されるロールのパーミッションが含まれているか否かを確認する。図８で説明したように、スコープ８０２の情報には、パーミッションが含まれている。このため、このスコープ８０２のパーミッションに、削除されるロールのパーミッションが含まれているか否かを確認することで、発行済みアクセストークンの認可情報に影響があるか否かを判断できる。
【００９５】
続いて、ステップＳ１１０５において、発行済みアクセストークン管理部６０６は、ステップＳ１１０３で取得したスコープ８０２の情報に含まれるパーミッションに、削除されるロールのパーミッションが含まれているかを判断する。
【００９６】
ステップＳ１１０５の判断の結果、ステップＳ１１０３で取得したスコープ８０２の情報に含まれるパーミッションに、削除されるロールのパーミッションが含まれている場合には（Ｓ１１０５／ＹＥＳ）、ステップＳ１１０６に進む。
ステップＳ１１０６に進むと、発行済みアクセストークン管理部６０６は、ロールの変更・削除が発行済みの署名付きアクセストークンに影響する（ロールの変更・削除により当該署名付きアクセストークンが無効になる）ため、その署名付きアクセストークンを記憶する。
【００９７】
また、ステップＳ１１０５の判断の結果、ステップＳ１１０３で取得したスコープ８０２の情報に含まれるパーミッションに、削除されるロールのパーミッションが含まれていない場合には（Ｓ１１０５／ＮＯ）、ステップＳ１１０６の記憶処理は行わない。
【００９８】
そして、ステップＳ１１０１で取得した全ての署名付きアクセストークンについて、ステップＳ１１０３〜Ｓ１１０６の処理を行い、その後、ステップＳ１１０７に進む。
【００９９】
ステップＳ１１０７に進むと、発行済みアクセストークン管理部６０６は、ステップＳ１１０６で記憶した署名付きアクセストークンがあるか否かを判断する。
【０１００】
ステップＳ１１０７の判断の結果、ステップＳ１１０６で記憶した署名付きアクセストークンがない場合には（Ｓ１１０７／ＮＯ）、ステップＳ１１０８に進む。
ステップＳ１１０８に進むと、ロール管理部６０４は、即座に、変更・削除指示があったロールの変更・削除を行う。このステップＳ１１０８の処理が終了すると、図１１のフローチャートにおける処理を終了する。
【０１０１】
一方、ステップＳ１１０７の判断の結果、ステップＳ１１０６で記憶した署名付きアクセストークンがある場合には（Ｓ１１０７／ＹＥＳ）、ステップＳ１１０９に進む。
ステップＳ１１０９に進むと、発行済みアクセストークン管理部６０６は、ステップＳ１１０６で記憶した署名付きアクセストークンの数を設定するとともに、当該署名付きアクセストークンを１つずつ処理対象として参照する。
【０１０２】
続いて、ステップＳ１１１０において、発行済みアクセストークン管理部６０６は、処理対象の署名付きアクセストークンにおける現在日時からの残りの有効期限を取得する。
【０１０３】
そして、ステップＳ１１０６で記憶した全ての署名付きアクセストークンについて、ステップＳ１１１０の処理を行い、その後、ステップＳ１１１１に進む。
【０１０４】
ステップＳ１１１１に進むと、発行済みアクセストークン管理部６０６は、ステップＳ１１１０で取得した残有効期限の最大値を取得する。
【０１０５】
続いて、ステップＳ１１１２において、予約情報管理部６０８は、ステップＳ１１１０で取得した残有効期限の最大値の後にロールの変更・削除を行うようにスケジュールした予約情報の管理を行う。そして、予約情報実行部６０９は、予約情報管理部６０８で管理されている予約情報に基づいて、最大値に係る残有効期限が経過した後に、当該ロールを変更・削除して管理情報を変更する処理を行う。この管理情報を変更する処理を行う予約情報実行部６０９は、変更手段を構成する。その後、図１１のフローチャートにおける処理を終了する。
【０１０６】
なお、ステップＳ１１１２では、有効期限が終了するタイミングに合わせてロールの変更・削除を行うようにスケジュールした例を挙げたが、本実施形態においては、これに限定されるものではない。例えば、アクセストークンの有効期限が固定であったり、設定可能な有効期限の最大値が決まっていたりする場合には、その定義した値の後にロールの変更・削除等を行う形態であってもよい。
【０１０７】
また、図１１では、管理情報の変更として、ロールの変更・削除を行う場合の例を示したが、本実施形態においては、これに限定されるものではない。例えば、図７に示すライセンス７０３の変更・削除を行う場合も適用可能である。このライセンス７０３の変更・削除を行う場合には、ライセンス７０３の変更・削除によって変更・削除されるロール７０４の全てについて、図１１のフローチャートにおける処理を実行する必要がある。また、ライセンス７０３の変更・削除は、図７に示すテナント７０１に登録されている全てのユーザー７０２に影響を及ぼすことになるため、図１１のステップＳ１１０１においてテナント７０１の全てのユーザー７０２に関して有効期限内の署名付きアクセストークンを確認する必要がある。
【０１０８】
図１２は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１において、アクセストークンの発行処理に係る処理手順の一例を示すフローチャートである。この図１２に示すアクセストークンの発行処理では、図１０と同様に、署名付き／署名なしの両方のアクセストークンの発行が対象となる。
【０１０９】
アクセストークンの発行指示があった場合、まず、ステップＳ１２０１において、ロール管理部６０４は、当該アクセストークンのオーナーとなるユーザーに付与されたロールを取得する。
【０１１０】
続いて、ステップＳ１２０２において、アクセストークン発行部６０５は、ステップＳ１２０１で取得されたロールから、発行するアクセストークンのパーミッションを持っているか否かを確認する。ここで、パーミッションを持っていれば、アクセストークンの発行権限があることになるため、このステップＳ１２０２では、アクセストークンの発行権限があるか否かを確認することになる。
【０１１１】
続いて、ステップＳ１２０３において、アクセストークン発行部６０５は、ステップＳ１２０２の確認の結果に基づき、発行権限があるか否かを判断する。
【０１１２】
ステップＳ１２０３の判断の結果、発行権限がない場合には（Ｓ１２０３／ＮＯ）、アクセストークンの発行はできないため、図１２のフローチャートにおける処理を終了する。
【０１１３】
一方、ステップＳ１２０３の判断の結果、発行権限がある場合には（Ｓ１２０３／ＹＥＳ）、ステップＳ１２０４に進む。
ステップＳ１２０４に進むと、予約情報管理部６０８は、設定変更・削除の予約情報を取得する。
【０１１４】
続いて、ステップＳ１２０５において、アクセストークン発行部６０５は、ステップＳ１２０４で取得した予約情報の数を設定するとともに、予約情報を１つずつ処理対象として参照する。
【０１１５】
続いて、ステップＳ１２０６において、アクセストークン発行部６０５は、処理対象の予約情報が、アクセストークンのオーナーとなるユーザーに関連する予約情報であるか否かを判断する。このステップＳ１２０６の処理では、処理対象の予約情報が、ユーザー７０２の変更・削除に係るものであれば該当ユーザーが対象なのか否かを確認し、ロール７０４やライセンス７０３の変更・削除に係るものであれば該当ユーザーが対象となるロールを持っているか否かを確認することで判断を行う。ここで、本実施形態においては、予約情報で変更・削除する対象が、ユーザー７０２、ロール７０４及びライセンス７０３のうちのいずれかであるものとして、以下の説明を行う。
【０１１６】
ステップＳ１２０６の判断の結果、アクセストークンのオーナーとなるユーザーに関連する予約情報である場合には（Ｓ１２０６／ＹＥＳ）、ステップＳ１２０７に進む。
ステップＳ１２０７に進むと、アクセストークン発行部６０５は、変更・削除の対象がロール７０４またはライセンス７０３であるか否かを判断する。
【０１１７】
ステップＳ１２０７の判断の結果、変更・削除の対象がロール７０４またはライセンス７０３でない場合には（Ｓ１２０７／ＮＯ）、本実施形態においては、変更・削除の対象がユーザー７０２となる。この変更・削除の対象がユーザー７０２である場合には、アクセストークンの発行はできないため、図１２のフローチャートにおける処理を終了する。なお、ここでのユーザー７０２の変更・削除は、ユーザー情報全体の削除やユーザーＩＤの変更等、アクセストークンの発行に係る情報を指すものとする。また、図１２のフローチャートには含めていないが、アクセストークンの有効期限が関連する予約情報の全ての予約日時前に収まっている場合には、アクセストークンを発行することも可能である。
【０１１８】
一方、ステップＳ１２０７の判断の結果、変更・削除の対象がロール７０４またはライセンス７０３である場合には（Ｓ１２０７／ＹＥＳ）、ステップＳ１２０８に進む。
ステップＳ１２０８に進むと、ロール管理部６０４或いは予約情報管理部６０８は、変更・削除された後の状態において該当ユーザーに付与されることになるロールを取得する。
【０１１９】
続いて、ステップＳ１２０９において、アクセストークン発行部６０５は、ステップＳ１２０８で取得されたロールから、発行するアクセストークンのパーミッションを持っているか否かを確認する。ここで、パーミッションを持っていれば、アクセストークンの発行権限があることになるため、このステップＳ１２０９では、アクセストークンの発行権限があるか否かを確認することになる。
【０１２０】
続いて、ステップＳ１２１０において、アクセストークン発行部６０５は、ステップＳ１２０９の確認の結果に基づき、発行権限があるか否かを判断する。
【０１２１】
ステップＳ１２１０の判断の結果、発行権限がない場合には（Ｓ１２１０／ＮＯ）、アクセストークンの発行はできないため、図１２のフローチャートにおける処理を終了する。
【０１２２】
そして、ステップＳ１２０４で取得した全ての予約情報について処理を行った結果、発行権限がある場合には（Ｓ１２１０／ＹＥＳ）、ステップＳ１２１１に進む。
ステップＳ１２１１に進むと、アクセストークン発行部６０５は、アクセストークンを発行する。その後、図１２のフローチャートにおける処理を終了する。
【０１２３】
上述した例では、認証・認可サーバー２０１の管理情報の変更（削除を含む）を、指示のタイミングより後に予約する対応について説明したが、管理情報の変更（削除を含む）タイミングを遅らせることはできるだけ避けたい。このような対応を取る必要が生じるのは、認証・認可サーバー２０１とリソースサーバー２０４がネットワーク上遠い位置に存在し、処理のパフォーマンスの低下を招くためである。仮に、認証・認可サーバー２０１とリソースサーバー２０２とのようにネットワーク上近い位置にあれば、署名付きアクセストークンを発行しなくても済む。この点を考慮して、管理情報の変更（削除を含む）タイミングを遅らせることを減らすための方法について、図１３及び図１４を用いて説明する。
【０１２４】
図１３は、本発明の実施形態に係る情報処理システム１３００の他の概略構成の一例を示す図である。具体的に、図１３に示す情報処理システム１３００は、マルチリージョン環境下における認証・認可サーバーとリソースサーバーのネットワーク構成を示している。なお、図１３において、図２に示す構成と同様の構成については同じ符号を付している。また、図１３に示す情報処理システム１３００では、図２に示すクライアント２０３は図示されていないが、本実施形態においては、図１３に示すインターネット２１０に、図２に示すコンピュータネットワーク２１２を介してクライアント２０３が接続されているものとする。
【０１２５】
ネットワーク１３１０には、認証・認可サーバー２０１、リソースサーバー１３１１及び１３１２が接続されている。このリソースサーバー１３１１及び１３１２は、図１３に示すように、それぞれ、サービスＡ及びサービスＢを提供する情報処理装置１００である。
【０１２６】
図１３において、インターネット２１０を跨いだ別のネットワーク１３２０には、リソースサーバー１３２１及び１３２２が接続されている。このリソースサーバー１３２１及び１３２２は、図１３に示すように、それぞれ、サービスＡ及びサービスＣを提供する情報処理装置１００である。
【０１２７】
図１３において、インターネット２１０を跨いだ更に別のネットワーク１３３０には、リソースサーバー１３３１及び１３３２が接続されている。このリソースサーバー１３３１及び１３３２は、図１３に示すように、それぞれ、サービスＡ及びサービスＤを提供する情報処理装置１００である。
【０１２８】
図１３において、ネットワーク１３１０、１３２０及び１３３０は、別のリージョンであり、国が異なる場合もある。また、図１３には記載していないが、各リージョンには、それぞれ、認証・認可サーバーが存在する場合が考えられる。特に国が異なる場合には、それぞれの国でユーザー情報を管理することが多い。
【０１２９】
サービスＡを提供するリソースサーバー１３１１、１３２１及び１３３１は、各リージョンに存在している。これは、各リージョンにおいて、認証・認可サーバーとリソースサーバーとが同一のリージョン内に存在することによって、情報の管理をしやすくしたり、処理のパフォーマンスを向上させたりすることに繋がるためである。
【０１３０】
一方、サービスＢを提供するリソースサーバー１３１２や、サービスＣを提供するリソースサーバー１３２２、サービスＤを提供するリソースサーバー１３３２は、それぞれのリージョンだけにサービスを提供する。別リージョンの認証・認可サーバーを使ってアクセスする場合には、処理のパフォーマンスの低下が懸念されるため、上述した署名付きアクセストークンの利用が推奨される。
【０１３１】
図１４は、本発明の実施形態に係る認証・認可サーバー（情報処理装置）２０１において、署名付きアクセストークンと署名なしアクセストークンとを切り替えて発行する際の処理手順の一例を示すフローチャートである。なお、図１２で説明したアクセストークン発行処理の内容は、後述するアクセストークン発行処理（Ｓ１４０４，Ｓ１４０９）、署名付きアクセストークン発行処理（Ｓ１４０５，Ｓ１４１６）に内包されるものとする。
【０１３２】
図１４において、アクセストークンの発行指示があると、まず、ステップＳ１４０１において、アクセストークン発行部６０５は、クライアント２０３から利用するサービスのリージョン情報を取得する。このリージョン情報は、クライアント２０３側で同一のリージョンのサービスへアクセスすることが分かっていた場合に、図３のステップＳ３０１或いは図４のステップＳ４０１で説明したアクセストークン取得時に認証・認可サーバー２０１に渡される情報である。このリージョン情報は、任意であり、設定されていない場合もある。
【０１３３】
続いて、ステップＳ１４０２において、アクセストークン発行部６０５は、ステップＳ１４０１で取得したリージョン情報が設定されているか否かを判断する。
【０１３４】
ステップＳ１４０２の判断の結果、ステップＳ１４０１で取得したリージョン情報が設定されている場合には（Ｓ１４０２／ＹＥＳ）、ステップＳ１４０３に進む。
ステップＳ１４０３に進むと、アクセストークン発行部６０５は、ステップＳ１４０１で取得したリージョン情報に係るリージョンが、認証・認可サーバー２０１と同一のリージョンであるか否かを判断する。
【０１３５】
ステップＳ１４０３の判断の結果、認証・認可サーバー２０１と同一のリージョンである場合には（Ｓ１４０３／ＹＥＳ）、ステップＳ１４０４に進む。
ステップＳ１４０４に進むと、アクセストークン発行部６０５は、署名なしアクセストークンを発行する。この場合、アクセストークンの検証におけるシーケンスは、図３に示す流れになり、図１１のステップＳ１１０１で取得されるアクセストークンの対象外となる。このステップＳ１４０４の処理が終了すると、図１４のフローチャートにおける処理を終了する。
【０１３６】
一方、ステップＳ１４０３の判断の結果、認証・認可サーバー２０１と同一のリージョンでない場合には（Ｓ１４０３／ＮＯ）、ステップＳ１４０５に進む。
ステップＳ１４０５に進むと、アクセストークン発行部６０５は、署名付きアクセストークンを発行する。このステップＳ１４０５の処理が終了すると、図１４のフローチャートにおける処理を終了する。
【０１３７】
また、ステップＳ１４０２の判断の結果、ステップＳ１４０１で取得したリージョン情報が設定されていない場合には（Ｓ１４０２／ＮＯ）、ステップＳ１４０６に進む。
ステップＳ１４０６に進むと、リソースサーバー情報管理部６１０は、発行依頼内容から利用するサービスを判定して取得する。例えば、図８の例では、スコープ８０２の情報として「ＰｒｉｎｔＵｓｅｒ」という情報が設定されているが、これは、図７のライセンス７０３の情報に含まれる印刷サービスと対応しており、この場合、アクセストークンが印刷サービスを利用するために発行されるものと判定できる。
【０１３８】
続いて、ステップＳ１４０７において、リソースサーバー情報管理部６１０は、ステップＳ１４０６で取得したサービスが同一のリージョンでの利用に制限しているか否かを確認する。これは、例えば、ユーザー情報と密接に関係した情報を保持するようなサービスであった場合に、同一のリージョンでの利用に制限される場合があり、認証・認可サーバー２０１が保持する連携リソースサーバーの情報として保持されている。
【０１３９】
続いて、ステップＳ１４０８において、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、ステップＳ１４０７の確認の結果に基づき、ステップＳ１４０６で取得したサービスが同一のリージョンでの利用に制限しているか否かを判断する。
【０１４０】
ステップＳ１４０８の判断の結果、ステップＳ１４０６で取得したサービスが同一のリージョンでの利用に制限している場合には（Ｓ１４０８／ＹＥＳ）、ステップＳ１４０９に進む。
ステップＳ１４０９に進むと、アクセストークン発行部６０５は、署名なしアクセストークンを発行する。このステップＳ１４０９の処理が終了すると、図１４のフローチャートにおける処理を終了する。
【０１４１】
一方、ステップＳ１４０８の判断の結果、ステップＳ１４０６で取得したサービスが同一のリージョンでの利用に制限していない場合には（Ｓ１４０８／ＮＯ）、ステップＳ１４１０に進む。
ステップＳ１４１０に進むと、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、連携するリソースサーバーの数を設定するとともに、連携するリソースサーバーを１つずつ処理対象として参照する。
【０１４２】
続いて、ステップＳ１４１１において、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、処理対象の連携するリソースサーバーが、発行するアクセストークンと同じサービスであるか否かを確認する。
【０１４３】
続いて、ステップＳ１４１２において、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、ステップＳ１４１１の確認の結果に基づき、発行するアクセストークンと同じサービスであるか否かを判断する。
【０１４４】
ステップＳ１４１２の判断の結果、発行するアクセストークンと同じサービスである場合には（Ｓ１４１２／ＹＥＳ）、ステップＳ１４１３に進む。
ステップＳ１４１３に進むと、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、そのリソースサーバーの情報を保持（記憶）する。
【０１４５】
そして、ステップＳ１４１０で設定した全ての連携するリソースサーバーについて、ステップＳ１４１１〜Ｓ１４１３の処理を行い、その後、ステップＳ１４１４に進む。
【０１４６】
ステップＳ１４１４に進むと、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、ステップＳ１４１３で保持（記憶）したリソースサーバーが全て同一のリージョンであるか否かを確認する。例えば、図１３において、アクセストークンがサービスＢを利用する場合には、サービスＢを提供するリソースサーバーがリソースサーバー１３１２しか存在しないため、この場合、全て同一のリージョンであると判断する。
【０１４７】
続いて、ステップＳ１４１５において、リソースサーバー情報管理部６１０或いはアクセストークン発行部６０５は、ステップＳ１４１４の確認の結果に基づき、ステップＳ１４１３で保持したリソースサーバーが全て同一のリージョンであるか否かを判断する。
【０１４８】
ステップＳ１４１５の判断の結果、ステップＳ１４１３で保持したリソースサーバーが全て同一のリージョンである場合には（Ｓ１４１５／ＹＥＳ）、ステップＳ１４０９に進む。そして、ステップＳ１４０９において、アクセストークン発行部６０５は、署名なしアクセストークンを発行する。このステップＳ１４０９の処理が終了すると、図１４のフローチャートにおける処理を終了する。
【０１４９】
一方、ステップＳ１４１５の判断の結果、ステップＳ１４１３で保持したリソースサーバーの全ては同一のリージョンでない場合（Ｓ１４１５／ＮＯ）、即ち別のリージョンでもサービスが提供されている場合には、ステップＳ１４１６に進む。
ステップＳ１４１６に進むと、アクセストークン発行部６０５は、署名付きアクセストークンを発行する。このステップＳ１４１６の処理が終了すると、図１４のフローチャートにおける処理を終了する。
【０１５０】
以上のように、アクセストークンの発行や検証を行うことにより、マルチリージョン環境下であっても処理のパフォーマンスを低下させることなく、且つ、認証・認可サーバー２０１の管理情報とアクセストークンとが矛盾せずにサービスを提供することができる。
【０１５１】
上述した例では、リソースサーバーへの影響を抑えた中で、認証・認可サーバー２０１の管理情報とアクセストークンとの間に矛盾が発生しないようにしてきた。しかしながら、図１４に示すフローチャートの処理を実施した場合でも、署名付きアクセストークンを発行する場合はあり、一方で緊急的に認証・認可サーバー２０１の管理情報を変更したい場合もある。その場合には、リソースサーバーにアクセストークンの無効依頼を通知する必要が出てくる。そのため、図１５及び図１６を用いて、リソースサーバーにアクセストークンの無効依頼を通知する場合の処理について説明する。
【０１５２】
図１５は、本発明の実施形態に係る情報処理システム２００における署名付きアクセストークンの発行と検証に関する処理手順の一例を示すシーケンス図である。この図１５では、便宜的に、図２に示す認証・認可サーバー２０１、クライアント２０３、及び、リソースサーバー２０４との間の連携を図示している。ただし、リソースサーバー２０４は、１つとは限らず、複数の場合もある。
【０１５３】
まず、ステップＳ１５０１において、クライアント２０３は、認証・認可サーバー２０１に対して認証情報或いは認可コードを渡して署名付きアクセストークンの発行を要求し、認証・認可サーバー２０１から署名付きアクセストークンを取得する。
【０１５４】
続いて、ステップＳ１５０２において、認証・認可サーバー２０１は、管理情報の変更（削除も含む）指示を受信する。
【０１５５】
続いて、ステップＳ１５０３において、認証・認可サーバー２０１は、変更（削除も含む）する管理情報に影響するアクセストークンに関連するリソースサーバーのリストを作成する。
【０１５６】
続いて、ステップＳ１５０４において、認証・認可サーバー２０１は、ステップＳ１５０３で作成したリストに記載の全てのリソースサーバー２０４に対して、アクセストークンの無効依頼を通知する。
【０１５７】
続いて、ステップＳ１５０５において、リソースサーバー２０４は、認証・認可サーバー２０１から無効依頼を受信し、無効依頼に係るアクセストークンの情報を保存する。その後、リソースサーバー２０４は、認証・認可サーバー２０１に対して、無効依頼に係るアクセストークンの情報を保存した旨を通知する。
【０１５８】
続いて、ステップＳ１５０６において、認証・認可サーバー２０１は、ステップＳ１５０２で受信した指示に基づき、該当する管理情報の変更（削除も含む）を行う。
【０１５９】
また、ステップＳ１５０７において、クライアント２０３は、認証・認可サーバー２０１から取得した署名付きアクセストークンを使って、リソースサーバー２０４に対してサービスの提供を要求する。
【０１６０】
続いて、ステップＳ１５０８において、リソースサーバー２０４は、クライアント２０３から受け取った署名付きアクセストークンが適正（有効）か否かについての検証を行う。ここでは、クライアント２０３から受け取った署名付きアクセストークンが、ステップＳ１５０５で保存した無効依頼に係るアクセストークンと一致するため、検証の結果、エラーと判定されることになる。その後、リソースサーバー２０４は、検証の結果、エラーと判定したため、サービスを提供するための処理を行わずに、クライアント２０３に対して検証結果がエラーの情報を送信する。
【０１６１】
ここで、リソースサーバー２０４の機能構成について説明する。
図１７は、本発明の実施形態に係るリソースサーバー（情報処理装置）２０４の機能構成の一例を示す図である。リソースサーバー２０４は、図１７に示すように、無効アクセストークン管理部１７０１、及び、アクセストークン検証部１７０２の各機能構成を有して構成されている。
【０１６２】
この図１７に示す各機能構成部１７０１〜１７０２は、例えば、図１に示す情報処理装置１００のハードウェア構成を有するリソースサーバー２０４のＣＰＵ１０１が記憶装置１０３に記憶されているプログラムを実行することにより、実現される。
【０１６３】
無効アクセストークン管理部１７０１は、図１５のステップＳ１５０５で保存される無効依頼に係る署名付きアクセストークンの情報を管理する。
【０１６４】
アクセストークン検証部１７０２は、認証・認可サーバー２０１で発行された署名付きアクセストークンの検証を行う。この際、アクセストークン検証部１７０２は、無効アクセストークン管理部１７０１で管理されている無効依頼に係る署名付きアクセストークンの情報も考慮した上で検証を行う。
【０１６５】
図１６は、本発明の実施形態に係る情報処理システム２００における管理情報の変更処理及び署名付きアクセストークンの無効処理に係る処理手順の一例を示すフローチャートである。この図１６において、図１１のフローチャートと同様の処理ステップについては、同じステップ番号を付している。具体的に、図１６は、図１１のフローチャートにおけるステップＳ１１０９〜Ｓ１１１２までの処理を拡張したものであり、図１６には、その拡張部分の処理手順が示されている。
【０１６６】
図１１のステップＳ１１０７においてＳ１１０６で記憶した署名付きアクセストークンがあると判断された場合（Ｓ１１０７／ＹＥＳ）、即ち署名付きアクセストークンがロールの変更・削除に関連していると判断された場合、図１６のステップＳ１６０１に進む。
ステップＳ１６０１に進むと、発行済みアクセストークン管理部６０６は、緊急にロールの変更・削除をする必要があるか否かを判断する。これは、例えば、変更・削除を行う利用者からの緊急性の有無に係る指示に基づき、判断する。
【０１６７】
ステップＳ１６０１の判断の結果、緊急にロールの変更・削除をする必要がない場合には（Ｓ１６０１／ＮＯ）、図１１のフローチャートと同様に、ステップＳ１１０９〜ステップＳ１１１２の処理を実施する。
【０１６８】
一方、ステップＳ１６０１の判断の結果、緊急にロールの変更・削除をする必要がある場合には（Ｓ１６０１／ＹＥＳ）、ステップＳ１６０２に進む。
ステップＳ１６０２に進むと、リソースサーバー情報管理部６１０は、連携するリソースサーバーの数を設定するとともに、連携するリソースサーバーを１つずつ処理対象として参照する。
【０１６９】
続いて、ステップＳ１６０３において、発行済みアクセストークン管理部６０６は、図１１のステップＳ１１０６で記憶した署名付きアクセストークンの数を設定するとともに、当該署名付きアクセストークンを１つずつ処理対象として参照する。
【０１７０】
続いて、ステップＳ１６０４において、発行済みアクセストークン管理部６０６或いはリソースサーバー情報管理部６１０は、署名付きアクセストークンが利用するサービスと同じサービスであるか否かを確認する。この際、同じサービスか否かについては、図１４のステップＳ１４１１と同様の処理で判断することができる。
【０１７１】
続いて、ステップＳ１６０５において、発行済みアクセストークン管理部６０６或いはリソースサーバー情報管理部６１０は、ステップＳ１６０４の確認の結果に基づき、署名付きアクセストークンが利用するサービスと同じサービスであるか否かを判断する。
【０１７２】
ステップＳ１６０５の判断の結果、署名付きアクセストークンが利用するサービスと同じサービスである場合には（Ｓ１６０５／ＹＥＳ）、ステップＳ１６０６に進む。
ステップＳ１６０６に進むと、発行済みアクセストークン管理部６０６或いはリソースサーバー情報管理部６１０は、そのリソースサーバーの情報を保持（記憶）する。
【０１７３】
そして、ステップＳ１６０３で設定した全ての署名付きアクセストークン、及び、ステップＳ１６０２で設定した全ての連携するリソースサーバーについて、ステップＳ１６０４〜Ｓ１６０６の処理を行い、その後、ステップＳ１６０７に進む。
【０１７４】
ステップＳ１６０７に進むと、リソースサーバー情報管理部６１０は、ステップＳ１６０６で保持（記憶）したリソースサーバーの全てに署名付きアクセストークンの無効依頼を送信する。例えば、図１３に示すような情報処理システムにおいて、サービスＡを利用するアクセストークンであった場合には、サービスＡを提供するリソースサーバー１３１１、１３２１及び１３３１に対して無効依頼を送信することになる。なお、このステップＳ１６０７の処理は、図１５のステップＳ１５０４の処理に対応している。
【０１７５】
続いて、ステップＳ１６０８において、発行済みアクセストークン管理部６０６は、無効依頼を送信したリソースサーバーの全てから、当該無効依頼に係るアクセストークンの情報を保存した等の無効処理に係る成功の通知を受信したか否かを判断する。
【０１７６】
ステップＳ１６０８の判断の結果、無効依頼を送信したリソースサーバーの全てから、無効処理に係る成功の通知を受信した場合には（Ｓ１６０８／ＹＥＳ）、ステップＳ１６０９に進む。
ステップＳ１６０９に進むと、ロール管理部６０４は、変更・削除指示があったロールを変更・削除して管理情報を変更する処理を行う。この管理情報を変更する処理を行うロール管理部６０４は、変更手段を構成する。ステップＳ１６０９の処理が終了すると、図１６のフローチャートにおける処理を終了する。
【０１７７】
一方、ステップＳ１６０８の判断の結果、無効依頼を送信したリソースサーバーの全てからは、無効処理に係る成功の通知を受信していない場合には（Ｓ１６０８／ＮＯ）、ステップＳ１６１０に進む。
ステップＳ１６１０に進むと、発行済みアクセストークン管理部６０６は、緊急にはロールの変更・削除ができないため、変更・削除指示を行った管理者等に対してエラーを送信する。このステップＳ１６１０の処理が終了すると、図１６のフローチャートにおける処理を終了する。
【０１７８】
以上説明した本実施形態に係る認証・認可サーバー（情報処理装置）２０１では、管理情報を変更する指示があった場合、アクセストークン発行部６０５から発行されたアクセストークンであって当該変更により無効となるアクセストークンの残りの有効期限を取得する（図１１及び図１６のＳ１１０９〜Ｓ１１１１）。そして、本実施形態に係る認証・認可サーバー（情報処理装置）２０１では、当該取得した残りの有効期限が経過した後に、管理情報を変更する処理を行うようにしている（図１１及び図１６のＳ１１１２）。
かかる構成によれば、認証・認可に係る管理情報に変更が生じる場合においても、アクセストークンを用いた適正な認証・認可を行うことができる。
【０１７９】
さらに、本実施形態に係る認証・認可サーバー（情報処理装置）２０１では、管理情報を緊急に変更する指示があった場合（図１６のＳ１６０１／ＹＥＳ）、当該変更により無効となるアクセストークンが利用するサービスを提供する他の情報処理装置に対して、当該アクセストークンの無効依頼を送信するようにしている（図１６のＳ１６０７）。そして、本実施形態に係る認証・認可サーバー（情報処理装置）２０１では、当該他の情報処理装置から無効依頼に基づく無効処理を行った旨の通知を受信した場合に（図１６のＳ１６０８／ＹＥＳ）、管理情報を変更する処理を行うようにしている（図１６のＳ１６０９）。
かかる構成によれば、さらに、認証・認可に係る管理情報を緊急に変更する必要がある場合も対応することが可能となる。
【０１８０】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
このプログラム及び当該プログラムを記憶したコンピュータ読み取り可能な記憶媒体は、本発明に含まれる。
【０１８１】
なお、上述した本発明の実施形態は、いずれも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１８２】
２０１：認証・認可サーバー、６０１：テナント管理部、６０２：ユーザー管理部、６０３：ライセンス管理部、６０４：ロール管理部、６０５：アクセストークン発行部、６０６：発行済みアクセストークン管理部、６０７：アクセストークン検証部、６０８：予約情報管理部、６０９：予約情報実行部、６１０：リソースサーバー情報管理部
【図１】
2018032085.tif 000003
【図２】
2018032085.tif 000004
【図３】
2018032085.tif 000005
【図４】
2018032085.tif 000006
【図５−１】
2018032085.tif 000007
【図５−２】
2018032085.tif 000008
【図６】
2018032085.tif 000009
【図７】
2018032085.tif 000010
【図８】
2018032085.tif 000011
【図９】
2018032085.tif 000012
【図１０】
2018032085.tif 000013
【図１１】
2018032085.tif 000014
【図１２】
2018032085.tif 000015
【図１３】
2018032085.tif 000016
【図１４】
2018032085.tif 000017
【図１５】
2018032085.tif 000018
【図１６】
2018032085.tif 000019
【図１７】
2018032085.tif 000020