JP6806543B2 - 権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法 - Google Patents

Description

本発明は、例えば権限検証を行う主体とリソース管理を行う主体が異なる場合等の、リソースごとの権限検証を可能とする権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法に関する。

リソースに対するアクセスを制御するために従来、たとえばOS管理下のファイルについては、OSがユーザーやユーザーグループごとのアクセスの許可や拒否を制御できていた。これは、ファイル管理も権限検証も、共にOSが実施していたためである。OS管理下のリソースに対するアクセス制御の振る舞いを切り替える方式として従来、ログイン時のパスワードにより権限を切り替える方式が提案されている（例えば特許文献１）。

特開2011-238258号公報

ここでクラウドサービスにおける、リソースに対する権限検証を考える。特に、ユーザーに機能を提供する複数のアプリケーションサービスを含むクラウドサービスを考える。この場合ユーザーの権限検証は、各機能を提供するアプリケーションサービスごとに実現するのでなく、認証・認可サービスのような一か所に集約したサービスとして実現する事が一般的である。これはセキュリティに関する機能は一か所に集約し、集約した箇所を重点的にセキュリティ向上させるのがよいためである。この場合、認証・認可サービスは複数のアプリケーションサービスと連携することになるため、アプリケーションサービスのリソースは各々のアプリケーションサービスに対応するリソースサーバー上で管理することが適当と考えられる。ユーザーに複数の機能を提供するクラウドサービスを考えた場合、権限検証を行う主体とリソース管理を行う主体とが、認証・認可サービスとアプリケーションサービスとにそれぞれ分散されることになる。この場合、各ユーザーが、各々のアプリケーションサービスのリソースごとに権限の範囲を変える仕組みがない。そのため、たとえばユーザーごとに、リソースごとの権限を付与し、ユーザーごとにその権限を認証または認可することは困難であった。また、認証・認可サービスにおいて、ユーザーごとにリソース別の権限を管理するとしても、リソースの変更があれば権限についてもその変更を反映しなければならず、権限管理の整合性や簡便性に問題が生じ得る。

本発明は前述の課題を鑑みてなされたもので、利便性や整合性を維持しつつユーザーごと且つリソースごとに異なる権限制御を行うことができる権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

本発明の第一の側面によれば、リソースに対するアクセス権限を検証する権限検証システムであって、
リソースごとに定めたリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、
ユーザー権限を管理するユーザー権限管理手段と、
指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定し、前記ユーザー権限管理手段で管理された前記ユーザー権限に基づいて、前記アクセス要求の送信元が有するユーザー権限を特定する特定手段と、
前記特定手段で特定された前記指定されたリソースに対して有する権限で、特定された前記ユーザー権限を絞り込んでアクセス権限を決定する絞り込み手段と、
前記絞り込み手段により絞り込まれた前記アクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるか判定する検証手段と、
前記検証手段により前記アクセスが許可されると判定された場合には、前記送信元に、前記リソースに対するアクセスを許す手段と
を有する。

また本発明の第２の側面によれば、リソースに対するアクセスを提供するリソースサーバーであって、
リソースごとのリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、
指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定する特定手段と、
前記特定手段により特定した前記指定されたリソースに対して有する権限と、認証サーバーが有するユーザーごとのユーザー権限とに基づいたアクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるかの判定を認証サーバーに要求する手段と、
前記認証サーバーからの応答に基づいて前記アクセスが許可されると判定された場合には、前記アクセス要求の送信元に、前記リソースに対するアクセスを許す手段とを有する。

また本発明の第３の側面によれば、リソースに対するアクセス権限を検証する認証サーバーであって、
ユーザごとのユーザー権限を管理するユーザー権限管理手段と、
リソースに対するアクセス権限の判定の要求に応じて、該要求と共に受信したリソース別ユーザー権限と、前記ユーザー権限管理手段により管理された前記ユーザー権限とに基づいて、リソースに対するアクセスが許可されるか判定する検証手段と、
前記検証手段による判定結果を前記要求の要求元に応答する手段と
を有する。

本発明によれば、利便性や整合性を維持しつつユーザーごと且つリソースごとに異なる権限制御を行うことができる。またその際に、リソース別のユーザーの権限について認証サーバーで管理する必要がなくなる。

ネットワーク構成を示す図である。 本発明の実施の形態に係るサーバーコンピューターの構成図である。 本実施の形態に係るモジュール構成図である。 本実施の形態に係るトークン発行フローである。 本実施の形態に係るリソースアクセス処理フローである。 本実施の形態に係る権限検証フローである。 本実施の形態に係る画面例を示す図である。 本実施の第２の形態に係るモジュール構成図である。 本実施の第２の形態に係る権限付与および解除フローである。 本実施の第３の形態に係るモジュール構成図である。 本実施の第３の形態に係るリソースアクセス処理フローである。 本実施の第３の形態に係る権限検証フローである。

以下、本発明を実施するための形態について図面を用いて説明する。なお本実施の形態では、次のようなシステムを考える。たとえば、地区ごとの複合機の稼働情報を管理する、複合機管理サービスを考える。ここで、あるユーザーＸはＡ地区の複合機管理担当であり、Ａ地区の複合機の情報を、アプリケーションサービスのひとつである複合機管理サービスに登録する。ユーザーＸは、Ｂ地区の複合機の情報については、複合機管理サービスに登録できないが、参照できる必要があるケースを考える。ここで、認証・認可サービスが「ユーザーＸはＡ地区情報登録権限およびＢ地区情報参照権限を持つ」という権限管理ができれば、前述のケースを実現できる。しかし実際には、複合機管理サービスの運用中に新たにＣ地区が追加されることも考えられる。前述の方式では、地区が追加されるたびに認証・認可サービスに対して権限定義の追加が必要になる。このため権限定義が際限なく増えることで認証・認可サービスの負荷が増えてしまう。認証・認可サービスは複合機管理サービスのみならず、その他のサービスに対する認証・認可処理を実行する可能性が高いため、1つのサービスのために負荷をかけることは現実的ではない。

一方、別の方法として地区が追加されるたびに権限定義されることがないよう、認証・認可サービスでは「ユーザーＸは登録権限および参照権限を持つ」のように、地区を意識しない権限管理することを考える。この場合、ユーザーＸはＡ地区情報登録権限およびＢ地区情報参照権限を持つことは実現できるが、権限が地区と紐付いていないため、ユーザーＸがＢ地区情報登録権限およびＡ地区情報参照権限も持つことになってしまう。これは、権限が過剰に割り当てられ、リソースごとにできることを切り替えられていないことになる。

次に説明する本願発明を実施することでこれらの問題を解決しつつ、本願発明の課題に記載した問題を解決することが可能になる。

［第１実施形態］
本実施の形態に係る権限移譲システム（あるいは認証システムあるいは権限検証システム）は、図１に示すような構成のネットワーク上に実現される。ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（広域ネットワーク）であり、本実施の形態においてはＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１およびＬＡＮ１０２は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ローカルエリアネットワーク）である。

認証・認可サーバー１５１（認証サーバー１５１と呼ぶこともある。）はユーザーの認証、認可および認証トークンおよびアクセストークンの発行および検証を行う。リソースサーバー１５２はリソースを管理する。アプリケーションサーバー１５３は、たとえばユーザー端末１９１からの要求に応じてサービスを提供する。ここで認証トークンとは、あるユーザーがシステムの正当な利用者であることを証明するひとまとまりの情報である。またアクセストークンとは、たとえばアプリケーションサーバー１５３上で稼働するあるアプリケーションが、ユーザーに、なんらかの操作（あるいは特定の操作）を許可されたことを証明するひとまとまりの情報であり、ユーザーがアプリケーションに対して認可操作することで発行される。アクセストークンは、ユーザーから委譲された権限を示す情報とも言え、たとえば権限の委譲元のユーザーや委譲された権限を示す情報などを含む。たとえばアプリケーションが、クラウドサービスが管理するリソースにアクセスするためのアクセストークンを用いると、そのアプリケーションは、認可操作したユーザーに許可された範囲でリソースにアクセスできるようになる。ユーザー端末１９１はユーザーにより操作される。各サーバーおよびユーザー端末１０１は例えばコンピュータである。

認証・認可サーバー１５１、リソースサーバー１５２はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。また同様にユーザー端末１９１はＷＡＮ１００およびＬＡＮ１０２を介して接続されている。なお認証・認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよいし、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認証・認可サーバー１５１、リソースサーバー１５２は図１ではそれぞれが1台として描かれているが複数のサーバーから構成されたサーバーシステムでも良く、例えば、複数台のサーバーをクラスタ化して認証・認可サーバー１５１を構成しても良い。なお、本願発明においてサーバーシステムと称した場合は、少なくとも1台のサーバーから構成された特定のサービスを提供する装置を指すものとする。

さらに、インターネットなどの広域ネットワーク１００には、ＬＡＮ１０３が接続され、ＬＡＮ１０３上にはＭＦＰ（多機能周辺装置あるいは画像形成装置）１３１が接続されている。ＭＦＰ１３１は、たとえば設定情報や、スキャンなどによって取得した画像データなどを保持することができる。また、ＭＦＰ１３１は、保持している情報のほか、スキャナ機能、プリンタ機能、画像処理機能などの機能を共有リソースとして、アクセス権限を付与されたアプリケーションサーバー１５３等に対して提供することができる。

＜サーバー及び端末のハードウェア＞
図２は本実施の形態に係る、認証・認可サーバー１５１の構成を示す図である。またリソースサーバー１５２の構成やユーザー端末１９１の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよびユーザー端末には一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ディスプレイコントローラ（ＣＲＴＣ）２０６は、ディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたプログラム、たとえばアプリケーションプログラムである。

＜認証・認可サーバーおよびリソースサーバーのソフトウェアモジュール構成＞
図３は本実施の形態に係る、認証・認可サーバー１５１、リソースサーバー１５２のモジュール構成を示す図である。図３（Ａ）は認証・認可サーバー１５１の、図３（Ｂ）はソースサーバー１５２のモジュール構成を、それぞれ示す。また図３（Ｃ）はユーザー端末１９１のモジュール構成を示す。認証・認可サーバー１５１は認証モジュール３０１、認可モジュール３０２、権限検証モジュール３０３を持つ。リソースサーバー１５２はリソースアクセス処理モジュール３５１、リソース別ユーザー権限記憶モジュール３５２、権限検証依頼モジュール３５３を持つ。ユーザー端末１９１はトークン要求モジュール３９１とリソース要求モジュール３９２を持つ。

認証モジュール３０１はユーザー端末１９１のトークン要求モジュール３９１からのトークン要求に応じ、ユーザー認証および認証トークンの発行を行う。また認可モジュール３０２は、同じくユーザー端末１９１のトークン要求モジュール３９１からのトークン要求に応じ、権限委譲や認可確認画面の表示やアクセストークンの発行を行う。権限検証モジュール３０３は認証モジュール３０１が発行した認証トークンもしくは認可モジュール３０２が発行したアクセストークンを用いて権限検証を行う。

リソースアクセス処理モジュール３５１はユーザー端末１９１のリソース要求モジュール３９２からリソース要求を受信する。リソース要求を受信すると、リソース別ユーザー権限記憶モジュール３５２や権限検証依頼モジュール３５３を用いてユーザーの権限を確認し、リソース要求を処理する。

リソースの具体例としては例えば、複合機管理サービスに登録された複合機をグルーピングした地区が考えられる。たとえばTokyo地区リソースと言った場合には、地理的にTokyoに設置されている複合機が紐付けられているとする。またTokyo地区リソースに対して複合機情報を取得するリソース要求と言った場合には、地理的にTokyoに設置されている複合機の情報を取得することとする。以下で単にリソースと表現した場合は、前述のような複合機が設置された地区およびその地区に紐付けられた複合機を示すものとする。ただし、本願のリソースは地区や複合機に限定されるものではない。

＜ログイン処理＞
図４（Ａ）は本実施の形態に係る、認証・認可サーバーにおけるログインフローである。本フローは認証・認可サーバー１５１がユーザー端末１９１からログイン要求を受信することで開始される。

ステップＳ４０１で認証モジュール３０１は、ユーザー端末１９１に対し、図７（Ａ）に示されるようなログイン画面１００１を送信する。ステップＳ４０２で認証モジュール３０１は、ログイン画面１００１で入力された認証情報を受け付ける。ステップＳ４０３で認証モジュール３０１は、ステップＳ４０２で受け付けた認証情報が妥当か、すなわち認証が成功したか判断する。ここで認証情報が妥当と判断された場合はステップＳ４０４に遷移する。また認証情報が妥当でないと判断された場合はステップＳ４１０に遷移する。妥当であるとは、例えば予め登録されている認証情報と、ユーザー端末１９１で入力された認証情報とが一致することである。

ステップＳ４０４で認証モジュール３０１は、ユーザーのログインを許可し、認証トークンを発行してフローを終了する。なおここで発行された認証トークンは、ユーザーと紐付けられ、表１に示されるような発行済みトークンテーブルで管理される。たとえば表１では、トークン識別子がAn0011223344のトークンは、トークン種別が認証トークンであり、ユーザーIDがUser Xであることを示す。また表１ではいずれの認証トークンにもスコープの設定はされていないことを示している。また同様にトークン識別子がAz99887766のトークンは、トークン種別がアクセストークンであり、ユーザーIDがUser Xであることを示す。またスコープとしてscope.MFP-ReadWriteおよびscope.MFP-Readが委譲されていることを示す。

ステップＳ４１０で認証モジュール３０１は、認証に失敗したユーザーのログインを拒否し、フローを終了する。なお本実施の形態に係るログインフローには、一般的なログインフローを適用できるものとする。

以上の手順で認証トークンを得たユーザー（あるいはユーザー端末あるいはユーザー端末で実行されるアプリケーションなど）は、認証トークを用いてたとえばアプリケーションサーバー１５３にサービス提供を要求し、サービスを受けることができる。

＜アクセストークンの発行処理＞
図４（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、アクセストークンの発行フローである。本フローは認証・認可サーバー１５１の認可モジュール３０２がユーザー端末１９１あるいはアプリケーションサーバー１５３などの要求元から、アクセストークンの要求を受信することで開始される。

ステップＳ４５１で認可モジュール３０２は、ユーザー端末１９１からアクセストークンの発行要求を受け付ける。ここで受け付けたアクセストークンの発行要求はユーザーの情報を含む。

ステップＳ４５２で認可モジュール３０２は、ユーザー端末１９１を操作しているユーザーがログイン済みか判断する。ここでユーザーがログイン済みと判断された場合はステップＳ４５５に遷移する。またログイン済みでないと判断された場合はステップＳ４５３に遷移する。ログイン済みであるか否かの判断は、たとえばステップＳ４５１のアクセストークンの発行要求に認証トークンが含まれるか否かで行われる。

ステップＳ４５３で認証モジュール３０１は、ユーザー端末１９１に対し、図７（Ａ）に示されるようなログイン画面１００１を送信する。なおログインフローの詳細は図４（Ａ）で示したものと同様である。

ステップＳ４５４で認証モジュール３０１は、ステップＳ４５３に対応してユーザーがログインしたか判断する。ここでユーザーがログインしたと判断されればステップＳ４５５に遷移する。またユーザーがログインしなかったと判断された場合はステップＳ４６０に遷移する。

ステップＳ４５５で認可モジュール３０２は、ユーザー端末１９１に対し、図７（Ｂ）に示すような認可確認画面１００２を送信し、ユーザーの確認を求める。認可確認画面１００２にはアクセスを許す範囲が表示され、ユーザーは、たとえばアプリケーションサービスによる表示されたデータへのアクセスを許可するのであれば「許可」ボタンを、拒否するのであれば「拒否」ボタンを押下する。認可モジュール３０２はそれぞれのボタンによる入力を受け付ける。アクセスを許す範囲は、対象となる情報の範囲に加えて、対象となる情報に対する操作の種別を含んでもよい。図７（Ｂ）の例では、対象となる情報として「ＭＦＰ情報」と表示され、対象となる操作の種類として、「読み取りと編集」が表示されている。この対象となる情報や操作の種類といったアクセスを許諾する範囲は、たとえばアクセストークンの発行要求とともに受信した情報に基づいている。

ステップＳ４５６で認可モジュール３０２は、ステップＳ４５５に対応してユーザーの認可を得られたか判断する。ここで認可を得られたと判断された場合はステップＳ４５７に遷移する。また認可を得られなかったと判断された場合はステップＳ４６０に遷移する。ユーザーが認可を行うために図７（Ｂ）にて許可を選択するための操作を認可操作と称し、ユーザーにより認可操作が行われたことでアクセストークンの発行が行われる。またここで認可された内容をスコープと称し、発行されたアクセストークンに認可された内容は、以下、スコープとして管理される。

ステップＳ４５７で認可モジュール３０２は、アクセストークンを発行し、ステップＳ４５１で受け付けたアクセストークンの発行要求に含まれるユーザー情報に紐付けて表１の発行済みトークンテーブルで記憶する。また発行したアクセストークンをユーザー端末１９１に返し、フローを終了する。なおここ発行されたアクセストークンは前述の表１に示されるような発行済みトークンテーブルで管理される。なお、OAuth2.0の様な権限委譲プロトコルでアクセストークンを発行しても良く、その場合は認可コードを発行するステップを加えることになる。発行したアクセストークンには、固有のトークン識別子が付与されており、それによってトークンを特定できる。またアクセストークンには、アクセスが許された例えば操作の種類が、スコープとして関連付けられる。スコープは、たとえばアクセストークンの発行要求とともに受信したアクセス範囲に基づいて設定される。発行済みトークンテーブルには、トークン識別子と発行したトークンの種別、ログインしているユーザーのユーザーＩＤ、許可されたアクセスの範囲（スコープ）が関連付けて登録される。

ステップＳ４６０で認可モジュール３０２は、アクセストークンを発行できない旨をユーザー端末１９１に通知し、フローを終了する。なお本実施の形態に係るアクセストークン発行フローには、一般的なアクセストークン発行フローを適用できるものとする。

以上の処理によって、アクセストークンを取得したアプリケーションは、そのアクセストークンを用いることで、ユーザーにより委譲された権限の範囲でリソースへアクセスすることができる。したがってアクセストークンが登録された表１に示した発行済みトークンテーブルおよびそれを管理するリソース別ユーザ権限記憶モジュール３５２は、リソースごとに定めたリソース別ユーザー権限を管理するリソース別ユーザー権限管理部ということもできる。

＜リソースへのアクセス処理＞
図５は本実施の形態に係る、リソースサーバー１５２におけるリソースアクセスの処理フローである。本フローはリソースサーバー１５２がユーザー端末１９１或いはユーザーから権限を移譲されたアプリケーションサーバー１５３からリソースアクセス要求を受信することで開始される。

ステップＳ５０１でリソースサーバー１５２のリソースアクセス処理モジュール３５１は、ユーザー端末１９１からのリソースアクセス要求を受け取る。ここでリソースアクセス要求には、認証トークンまたはアクセストークンと、アクセス対象リソースの指示と、リソースアクセスの操作内容を含む。リソースアクセス要求の送信元はたとえばユーザーから権限を移譲されたアプリケーションサーバー１５３などであってもよく、その場合にはリソースアクセス要求には、アクセストークンと、アクセス対象リソースの指示と、リソースアクセスの操作内容を含む。

ステップＳ５０２でリソースアクセス処理モジュール３５１は、ステップＳ５０１で指定された操作を実行するのに必要なスコープを解決する。なおこのスコープはアクセストークンに紐付くスコープと同様のものであり、権限検証に際しては、操作に必要なスコープがアクセストークンに紐付くことの確認が行われる。またユーザーがそのスコープを満たす権限を持つかも確認される。操作とスコープの対応関係は、たとえば表２に示されるような、操作別要求スコープテーブルで管理される。表２の例では、機器を管理するManageDevices操作に対してscope.MFP-ReadWriteというスコープが必要と定義されている。操作と対応するスコープとはたとえば予め決定しておき、表２の操作別要求スコープテーブルに保存しておけばよい。したがって、リソースサーバー１５２は、リソースアクセス要求と共に受け取った操作内容の指定に対応するスコープを操作別要求スコープテーブルから検索して、該当するスコープを一時的に保存しておく。そのスコープが要求された操作内容のために必要な権限を示す。

ステップＳ５０３でリソースアクセス処理モジュール３５１は、ステップＳ５０１で受け取った認証トークンもしくはアクセストークンを用いて認証・認可サーバー１５１に問い合わせることで、トークンに紐付くユーザーを解決する。問い合わせを受けた認証・認可サーバー１５１は、たとえば表１の発行済みトークンテーブルから、受けとったトークンのトークン識別子およびトークン種別に紐づけられたユーザーＩＤを検索する。該当するユーザーＩＤがあれば、それをリソースサーバー１５２に返す。

ステップＳ５０４でリソースアクセス処理モジュール３５１は、ステップＳ５０１で指定されたリソースにおいて、ステップＳ５０３で解決したユーザーが、どの権限で操作してよいかの権限情報を取得する。このリソース別のユーザー権限は、リソース別ユーザー権限記憶モジュール３５２が、表３に示すようなリソース別ユーザー権限テーブルで記憶する。表３ではArea-Aリソースに対し、User Xユーザーは、MFP-ReadWriteの権限で操作してよいことが示される。具体的には、地理的にArea-Aに設置された複合機に対し、User Xユーザーは、複合機の情報取得や設定変更ができるものとする。またあるユーザーの特定のリソースに対する権限が複数記憶されていた場合は、そのリソースに対し複数の権限のすべてを持つこととする。ステップＳ５０４では結局、指定されたリソースに対する特定されたユーザーの権限情報を得る。このようにリソース別ユーザー権限テーブルには、リソースを示す例えば識別情報とユーザーＩＤとその権限とが関連付けられて登録されている。リソース別ユーザー権限テーブルは、たとえばリソースサーバー１５１に保存され、その保守はたとえばユーザー端末１９１から、権限を持った管理者により行うことができてもよい。

ステップＳ５０５でリソースサーバー１５２の権限検証依頼モジュール３５３は、認証・認可サーバー１５１に対し、権限検証を依頼する。ここで権限検証依頼には、ステップＳ５０１で取得したトークンと、ステップＳ５０２で解決したスコープと、ステップＳ５０４で取得した権限情報を含む。認証・認可サーバー１５１は、受信した権限検証依頼に応じて権限検証を行う。この手順は図６で説明する。簡単に説明すれば、認証・認可サーバー１５１は、受信したトークンでたとえば表１の発行済みトークン情報を検索する。そして、該当するトークンに関連づけられたスコープが、権限検証依頼と共に受信した、操作のために必要なスコープをすべて含み、かつ、特定されたユーザーが指定されたリソースに対して有する権限をすべて含むか否かを判定する。すべて含んでいれば権限ありと判定される。またトークンに関連付けられたスコープではカバーできない権限を要する操作やリソースがあれば、権限なしと判定される。判定の結果はリソースサーバー１５２に送信される。

ステップＳ５０６でリソースアクセス処理モジュール３５１は、ステップＳ５０５の権限検証の結果、権限ありと判断されたか確認する。権限ありと判断された場合はステップＳ５０７に遷移し、権限なしと判断された場合はステップＳ５５０に遷移する。

ステップＳ５０７でリソースアクセス処理モジュール３５１は、ステップＳ５０１で受け取ったリソースアクセス要求を処理し、ユーザー端末１９１に結果を返してフローを終了する。リソースアクセス要求の処理では、その要求に応じてたとえばデータを読み出し、あるいはデータを更新し、あるいはメモリや計算リソースを確保するなどが行われる。

ステップＳ５５０でリソースアクセス処理モジュール３５１は、ステップＳ５０１で受け取ったリソースアクセス要求を処理できない旨を、ユーザー端末１９１に応答として返してフローを終了する。

以上の手順により、リソースサーバー１５２は、指定された操作が、受信したトークンに関連付けられたスコープで可能であるか判定し、可能であればそれを実行する。

＜権限検証処理＞
図６は本実施の形態に係る、認証・認可サーバー１５１における、認証トークンおよびアクセストークンを用いた権限検証フローである。本フローは認証・認可サーバー１５１の権限検証モジュール３０３が、リソースサーバー１５２の権限検証依頼モジュール３５３から権限検証依頼（図５のステップＳ５０５に相当）を受信することで開始される。

ステップＳ６０１で権限検証モジュール３０３は、リソースサーバー１５２の権限検証依頼モジュール３５３から権限検証依頼を受信する。ここで権限検証依頼にはリソースサーバー１５２のリソースアクセス処理モジュール３５１がユーザー端末１９１またはアプリケーションサーバー１５３から受信した認証トークンもしくはアクセストークンを含む。また前記権限検証依頼は、リソースサーバー１５２のリソースアクセス処理モジュール３５１がユーザー端末１９１またはアプリケーションサーバー１５３から要求されたリソースアクセスに必要なスコープも含む。さらに前記権限検証依頼は、リソースサーバー１５１のリソースアクセス処理モジュール３５１が、リソース別ユーザー権限記憶モジュール３５２から取得した、指定リソースに対するユーザーの権限情報も含む。

ステップＳ６０２で権限検証モジュール３０３は、ステップＳ６０１で受け取ったトークンが認証トークンであったかアクセストークンであったか判断する。トークンが認証トークンであった場合はステップＳ６０５に遷移し、アクセストークンであった場合はステップＳ６０３に遷移する。

ステップＳ６０３で権限検証モジュール３０３は、表１に示されるような発行済みトークンテーブルに問い合わせ、ステップＳ６０１で受け取ったアクセストークンに紐付くスコープを取得する。

ステップＳ６０４で権限検証モジュール３０３は、ステップＳ６０３で取得したアクセストークンに紐付くスコープが、ステップＳ６０１で受け取ったスコープをすべて含むか判断する。スコープをすべて含むと判断された場合はステップＳ６０５に遷移し、１つでも含まれないものがあると判断された場合はステップＳ６５０に遷移する。

ステップＳ６０５で権限検証モジュール３０３は、表４で示されるようなスコープテーブルに問い合わせ、ステップＳ６０１で受け取ったスコープで要求されるユーザーの権限を取得する。ここでリソース利用に必要なスコープがscope.MFP-ReadWriteだったとする。この場合、要求されるユーザーの権限はMFP-ReadWriteであると判断される。スコープテーブルは例えば認証・認可サーバー１５２に別途登録され、保守される。

ステップＳ６０６で権限検証モジュール３０３は、ステップＳ６０１で受け取ったトークンを元に表１で示される発行済みトークンテーブルを参照し、トークンに紐付けられたユーザーを解決する。たとえばトークンの識別子がAn0011223344であれば、トークンに紐付けられたユーザーはUser Xであると分かる。

ステップＳ６０７で権限検証モジュール３０３は、表５で示されるユーザー権限テーブルを参照し、ステップＳ６０１で受け取ったトークンに紐付けられたユーザーの権限を解決する。たとえばユーザーIDがUser Xであれば、その権限はMFP-ReadWriteおよびMFP-Readである。ユーザ権限テーブルは例えば認証・認可サーバー１５１に別途登録され、保守される。ユーザ権限テーブルおよびユーザー権限を管理する認証・認可サーバー１５１は、ユーザー権限管理部ということもできる。

ステップＳ６０８で権限検証モジュール３０３は、ステップＳ６０１で受け取った指定リソースに対するユーザーの権限情報を用いて、トークンに紐付けられたユーザーの権限を絞り込む。絞り込むことで得られた権限を、本実施形態および他の実施形態では他の権限と区別するためにアクセス権限と呼ぶこともある。受け取った権限情報は、１つの権限を示す情報でもよく、また複数の権限のリストを示す情報であってもよい。また空の権限リストや、リスト自体が存在しないことを意味するnull値であってもよい。受け取ったのがnull値の場合、空集合を受け取ったとして扱い、ユーザーの権限と空集合の積集合を取り、絞り込み結果を「権限なし」としてもよい。逆にnull値を受け取った場合は、トークンに紐付けられたユーザーの権限をそのまま利用することとしてもよい。その他の場合は、アクセストークンとともに受け取った権限情報とユーザーの権限との積集合を取ることで権限の絞り込みを行う。たとえばUser Xが持つ権限がMFP-ReadWriteおよびMFP-Readで、ステップＳ６０１で受け取った権限情報がMFP-ReadWriteであれば、絞り込んだ結果の権限はその共通部分であるMFP-ReadWriteとなる。なお、絞り込みとは、権限検証モジュール３０３が管理する特定のユーザーに対して与えられた権限の中から、リソースアクセス処理モジュール３５１が指定してきたその特定のユーザーが今回アクセスするリソースに対する権限と一致する権限を確認する処理と言える。権限検証モジュール３０３が管理する特定のユーザーの権限が削除されたわけではないことに留意されたい。

ステップＳ６０９で権限検証モジュール３０３は、ステップＳ６０８で絞り込んだ結果の権限、即ち確認の結果今回アクセスするリソースに対する権限と一致した権限検証モジュール３０３が管理する特定のユーザーに対して与えられた権限が、ステップＳ６０５で取得したスコープで要求される権限を満たすか判断する。要求されるすべての権限を持つと判断された場合はステップＳ６１０に遷移し、一部でも欠けていると判断されていた場合はステップＳ６５０に遷移する。たとえばステップＳ６０９では、スコープで要求される権限がMFP-ReadWriteで、絞り込んだ結果の権限がMFP-ReadWriteとすると、権限を満たすと判断される。このように絞り込みにより得られた、リソースに対するユーザーの権限が、スコープで要求される権限を包含する場合に権限を満たすと判定できる。ここで権限と権限との間の包含関係は、たとえばスコープで要求される権限がMFP-Readで、絞り込んだ結果の権限がMFP-ReadWriteであるような場合にも成立するとしてもよい。この場合には特定のリソースに対してMFP-ReadWriteの権限があればMFP-Readの権限でできることを全て行い得るので、MFP-ReadWriteの権限はMFP-Readの権限を包含するということができる。このように権限としては異なるものであっても、包含関係は成立し得る場合があり得る。

ステップＳ６１０で権限検証モジュール３０３は、ユーザーが、要求された権限を持つことを意味する判定結果をリソースサーバー１５２に返し、フローを終了する。

ステップＳ６５０で権限検証モジュール３０３は、ユーザーが、要求された権限を持たないことを意味する判定結果をリソースサーバー１５２に返し、フローを終了する。

本実施の形態によれば、権限検証は認証・認可サーバー１５１が、リソース管理はリソースサーバー１５２が行う場合において、ユーザーがそれぞれのリソースに対してどのような権限で操作を行ってよいか制御できるようになる。またその際に、リソース別のユーザーの権限について認証・認可サーバー１５１で管理する必要がなくなる。

［第２実施形態］
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。本実施の第１の形態でユーザーがリソースを操作できるためには、リソースサーバー１５２に対し、表３に示すようなリソース別ユーザー権限テーブルを設定する必要がある。さらに認証・認可サーバー１５１に対し、表５に示すようなユーザー権限テーブルの設定も必要である。このように２つのテーブルで権限設定が必要になるが、ユーザーが１度操作することで両方のテーブルに設定が反映されるのが好ましい。本実施の第２の形態は、前述の課題を鑑みて為されたものである。

＜リソースサーバーのモジュール構成＞
図８は本実施の第２の形態に係る、リソースサーバー１５２のモジュール構成を示す図である。ここでリソースサーバー１５２は、図３（Ｂ）の構成に加え、リソース別権限設定モジュール３６１を持つ。リソース別権限設定モジュール３６１はユーザー端末１９１の要求に応じて、表３で管理されるリソース別ユーザー権限を更新すると共に、認証・認可サーバー１５１に対して権限設定を指示する。これにより、リソース別のユーザーの権限を設定し、あるいは解除することができる。

＜権限付与処理＞
図９は本実施の第２の形態に係る、リソースサーバー１５２におけるユーザーに対する権限付与フローおよび権限解除フローである。図９（Ａ）は本実施の第２の形態に係る、リソースサーバー１５２におけるユーザーに対する権限付与フローである。本フローはリソースサーバー１５２が、ユーザー端末１９１から権限付与要求を受信することで開始される。本実施形態では、リソース別のユーザー権限は、図９（Ａ）の手順により表３のリソース別ユーザー権限テーブルに定義される。

ステップＳ９０１でリソースサーバー１５２は、リソース別の権限付与要求を受け付ける。ここで権限付与要求には、権限付与する対象ユーザー、対象リソース、および付与する権限の情報が含まれる。

ステップＳ９０２でリソース別権限設定モジュール３６１は、ステップＳ９０１で受け付けた権限付与要求に該当する権限が設定済みか確認する。権限が設定済みであればフローを終了し、権限が未設定であればステップＳ９０３に遷移する。権限が設定済みとは、たとえば権限付与要求と共に受け付けた対象ユーザー、対象リソースおよび権限情報に該当する項目が、リソース別ユーザー権限テーブルに登録済みであることである。

ステップＳ９０３でリソース別権限設定モジュール３６１は、ステップＳ９０１の権限付与要求で指定されたユーザーの、指定されたリソースに対し、指定された権限を、表３に示すようなリソース別ユーザー権限テーブルで記憶する。ここでたとえば、Area-Bに対するUser Yの権限は、MFP-ReadWriteと記憶されている。

ステップＳ９０４でリソース別権限設定モジュール３６１は、ステップＳ９０３で記憶したユーザーの権限の付与数をカウントアップして記憶する。付与数は表６に示すような権限付与カウントテーブルで記憶する。たとえばここで、User YにはMFP-ReadWriteが2つのリソースに対して付与されていることが記憶されている。なお表６の権限付与カウントテーブルは初期状態ではその内容は空であり、新たな登録に応じてユーザーＩＤおよび対応する権限を追加し、付与カウントとして１を登録する。その後は、付与カウントに、付与した権限の数に応じて１ずつ加算する。

ステップＳ９０５でリソース別権限設定モジュール３６１は、認証・認可サーバー１５１に、ステップＳ９０１で指定された対象ユーザーに、指定された権限を付与するよう指示し、フローを終了する。またこの権限付与指示に対応し、認証・認可サーバー１５１では、指示された権限を記憶する。具体的には、認証・認可サーバー１５１は、例えば表５で示されるユーザー権限テーブルに、該当するユーザーＩＤおよび権限情報を追加的に登録する。

＜権限解除処理＞
図９（Ｂ）は本実施の第２の形態に係る、リソースサーバー１５２におけるユーザーに対する権限の解除フローである。本フローはリソースサーバー１５２が、ユーザー端末１９１から権限解除要求を受信することで開始される。

ステップＳ９１１でリソースサーバー１５２は、リソース別の権限解除要求を受け付ける。ここで権限解除要求には、権限解除する対象ユーザー、対象リソース、および解除する権限の情報が含まれる。

ステップＳ９１２でリソース別権限設定モジュール３６１は、ステップＳ９１１で受け付けた権限解除要求に該当する権限が設定済みか確認する。権限が未設定であればフローを終了し、権限が設定済みであればステップＳ９１３に遷移する。

ステップＳ９１３でリソース別権限設定モジュール３６１は、ステップＳ９１１の権限解除要求で指定されたユーザーの、指定されたリソースに対し、指定された権限を持つという情報を、表３に示すようなリソース別ユーザー権限テーブルから削除する。

ステップＳ９１４でリソース別権限設定モジュール３６１は、ステップＳ９１３で削除したユーザーの権限の付与数を、表６の権限付与カウントテーブルでカウントダウンして記憶する。

ステップＳ９１５でリソース別権限設定モジュール３６１は、ステップＳ９１４の付与数カウントダウンの結果、ステップＳ９１１で指定されたユーザーの、指定された権限に関するカウントがゼロになったか確認する。たとえばステップＳ９１１で指定されたユーザーおよび権限がUser XとMFP-ReadWriteだったとすると、これはステップＳ９１４のカウントダウンによりカウントがゼロになったと判断される。カウントがゼロになった場合はステップＳ９１６に遷移し、ゼロになっていなければフローを終了する。

ステップＳ９１６でリソース別権限設定モジュール３６１は、認証・認可サーバー１５１に、ステップＳ９１１で指定された対象ユーザーの、指定された権限を解除するよう指示し、フローを終了する。またこの権限解除指示に対応し、認証・認可サーバー１５１では、指示された権限を解除する。具体的には、認証・認可サーバー１５１では、例えば表５で示されるユーザー権限テーブルから、該当するユーザーＩＤおよび権限情報を削除する。

以上説明したように本実施の第２の形態によれば、第１の実施形態におけるリソース別のユーザー権限を、リソースサーバー１５２により保守管理できるという利点に加えて、認証・認可サーバー１５１とリソースサーバー１５２のように異なるサーバーで管理される２つのテーブルに対する権限設定の利便性が向上する。具体的にはユーザーが１度操作することで、両方のテーブルに設定が反映されるようになる。

［第３実施形態］
次に、本発明を実施するための第３の形態について図面を用いて説明する。なお第１の実施の形態および第２の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。第３の実施形態は、第１の実施形のみ実施したシステム、もしくは第１の実施形と第２の実施形態の両方を実施したシステムにて実施される。昨今トークンとして、トークンID以外にも他に属性情報を持てるJSON Web Token（ジェイソンウエブトークン、以下、JWT）と呼ばれるトークンを用いる仕組みが検討されている。以下では、トークンとしてJWTを用い、主にリソースサーバー１５２側で処理を行うことで、認証・認可サーバー１５１の処理を低減する例を説明する。

＜認証・認可サーバーおよびリソースサーバーのモジュール構成＞
図１０は本実施の第３の形態に係る、認証・認可サーバー１５１およびリソースサーバー１５２のモジュール構成を示す図である。ここで認証・認可サーバー１５１は、図３（Ａ）の構成に加え、第２の権限検証モジュール３１１を持つ。またリソースサーバー１５２は、図３（Ｂ）の構成に加え、第２のリソースアクセス処理モジュール３７１および第２の権限検証依頼モジュール３７２を持つ。

本実施の第３の形態においては、ユーザー端末１９１（あるいはアプリケーションサーバー１５３）がJWTを用いて、リソースサーバー１５２に対してリソースアクセスを要求する。リソースアクセス要求を受信したリソースサーバー１５２の第２のリソースアクセス処理モジュール３７１は、リソース別ユーザー権限記憶モジュール３５２で記憶する権限に基づく権限の絞り込みを行う。第２の権限検証依頼モジュール３７２は、第２のリソースアクセス処理モジュール３７１が絞り込んだ権限に基づき、認証・認可サーバー１５１の第２の権限検証モジュール３１１に対して権限検証を依頼する。第２の権限検証モジュール３１１は絞り込みの済んだ権限情報を元に権限検証を行う。なお本実施の第３の形態においては、JWTは認証・認可サーバー１５１の認可モジュール３０２が発行するものとする。本例では特にJWTをアクセストークンとして利用する場合を説明する。なお認証・認可サーバー１５１はアクセストークンとJWTの両方を、トークンの要求に応じて発行してよい。この場合には例えば要求元が明示的にいずれかを示せばよい。あるいは、認証・認可サーバー１５１はいずれか一方のみを発行してもよい。後者の場合であっても、例えばアクセストークンを発行するサーバーとJWTを発行するサーバーとが混在していたり、いずれか一方から他方への移行の過渡期であったりすれば、両方のトークンが混在することもあり得る。

＜リソースアクセスの処理＞
図１１は本実施の第３の形態に係る、リソースサーバー１５２におけるリソースアクセスの処理フローである。本フローはリソースサーバー１５２が、ユーザー端末１９１あるいはアプリケーションサーバー１５３から、JWTを用いたリソースアクセス要求を受信することで開始される。

ステップＳ３５０１でリソースサーバー１５２の第２のリソースアクセス処理モジュール３７１は、ユーザー端末１９１あるいはアプリケーションサーバー１５３からのリソースアクセス要求を受け取る。ここでリソースアクセス要求には、JWTと、アクセス対象リソースの指示と、リソースアクセスの操作内容を含む。なおここで受け取るJWTは、表7に示されるような、電子署名やユーザーID、ユーザーの権限を含むとする。

ステップＳ３５０２で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で受け取ったJWTを、トークンに含まれる電子署名を用いて検証する。ここで署名に問題がなければステップＳ３５０３に遷移し、署名が不正と判断された場合はステップＳ３５５０に遷移する。

ステップＳ３５０３で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で指定された操作を実行するのに必要なスコープを、表２に示されるような操作別要求スコープテーブルを用いて解決する。

ステップＳ３５０４で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で受け取ったJWTからユーザーIDを取り出す。

ステップＳ３５０５で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で指定されたリソースにおいて、ステップＳ３５０４でJWTから取り出したユーザーが、どの権限で操作してよいか設定されている権限情報を取得する。このリソース別のユーザー権限は、リソース別ユーザー権限記憶モジュール３５２に問い合わせて、例えば表３のリソース別ユーザー権限テーブルから取得する。

ステップＳ３５０６で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で受け取ったJWTに含まれるユーザーの権限を、ステップＳ３５０５で取得した権限で絞り込む。絞り込みは、たとえば権限の共通部分をとることで行われる。

ステップＳ３５０７でリソースサーバー１５２の第２の権限検証依頼モジュール３７２は、認証・認可サーバー１５１に対し、権限検証を依頼する。ここで権限検証依頼には、ステップＳ３５０１で取得したトークンと、ステップＳ３５０３で解決したスコープと、ステップＳ３５０６で絞り込んだ権限情報を含む。認証・認可サーバー１５１による権限検証処理の手順は、図１２を参照して後述する。

ステップＳ３５０８で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０７の権限検証の結果、権限ありと判断されたか確認する。権限ありと判断された場合はステップＳ３５０９に遷移し、権限なしと判断された場合はステップＳ３５５０に遷移する。

ステップＳ３５０９で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で受け取ったリソースアクセス要求を処理し、ユーザー端末１９１に結果を返してフローを終了する。

ステップＳ３５５０で第２のリソースアクセス処理モジュール３７１は、ステップＳ３５０１で受け取ったリソースアクセス要求を処理できない旨を、ユーザー端末１９１に応答として返してフローを終了する。

＜リソースアクセスの権限検証処理＞
図１２は本実施の第３の形態に係る、認証・認可サーバー１５１における、JWTによるリソースアクセスの権限検証フローである。本フローは認証・認可サーバー１５１の第２の権限検証モジュール３１１が、リソースサーバー１５２の第２の権限検証依頼モジュール３７２から権限検証依頼を受信することで開始される。なおトークンが認証トークンもしくはアクセストークンの場合は図６のフローで処理されるものとして、ここではトークンがJWTの場合についてのみ説明する。

ステップＳ３６０１で第２の権限検証モジュール３１１は、リソースサーバー１５２の第２の権限検証依頼モジュール３７２から権限検証依頼を受信する。ここで権限検証依頼にはリソースサーバー１５２の第２のリソースアクセス処理モジュール３７１がユーザー端末１９１から受信したJWTを含む。また前記権限検証依頼は、リソースサーバー１５２の第２のリソースアクセス処理モジュール３７１がユーザー端末１９１から要求されたリソースアクセスに必要なスコープも含む。さらに前記権限検証依頼は、リソースサーバー１５１の第２のリソースアクセス処理モジュール３７１が、JWTに記載された権限を、リソース別ユーザー権限記憶モジュール３５２で記憶した権限で絞り込んだ権限情報も含む。

ステップＳ３６０２で第２の権限検証モジュール３１１は、表８に示されるような第２の発行済みトークンテーブルに問い合わせ、ステップＳ３６０１で受け取ったJWTに紐付くスコープを取得する。ここでステップＳ３６０１で受け取ったJWTの識別子がJWT0123456789であれば、取得されるスコープはscope.MFP-ReadWrite, scope.MFP-Readとなる。なお第２の発行済みトークンテーブルは、表１に示した発行済みトークンテーブルに代えて本実施形態で用いられる。表８は追加的に用いる場合の例である。この場合には、図４（Ｂ）のステップＳ４５７において、要求元の指定に応じてアクセストーンまたはＪＷＴを選択的に発行するようにしても良い。

ステップＳ３６０３で第２の権限検証モジュール３１１は、ステップＳ３６０２で取得したJWTに紐付くスコープが、ステップＳ３６０１で受け取ったスコープをすべて含むか判断する。スコープをすべて含むと判断された場合はステップＳ３６０４に遷移し、１つでも含まれないものがあると判断された場合はステップＳ３６５０に遷移する。

ステップＳ３６０４で第２の権限検証モジュール３１１は、表４で示されるようなスコープテーブルに問い合わせ、ステップＳ３６０１で受け取ったスコープで要求されるユーザーの権限を取得する。ここでリソース利用に必要なスコープがscope.MFP-ReadWriteだったとする。この場合、要求されるユーザーの権限はMFP-ReadWriteであると判断される。

ステップＳ３６０５で第２の権限検証モジュール３１１は、ステップＳ６０１で受け取った絞り込み済みの権限情報が、ステップＳ３６０４で取得した必要な権限をすべて含むか判断する。

ステップＳ３６０６で第２の権限検証モジュール３１１は、ステップＳ３６０５の判断の結果を確認する。要求されるすべての権限を持つと判断されていた場合はステップＳ３６０７に遷移し、一部でも欠けていると判断されていた場合はステップＳ３６５０に遷移する。

ステップＳ３６０７で第２の権限検証モジュール３１１は、ユーザーが、要求された権限を持つことを意味する結果をリソースサーバー１５２に返し、フローを終了する。

ステップＳ３６５０で第２の権限検証モジュール３１１は、ユーザーが、要求された権限を持たないことを意味する結果をリソースサーバー１５２に返し、フローを終了する。

本実施の第３の形態によれば、トークンとしてJWTを用い、主にリソースサーバー１５２側で処理を行うことで、認証・認可サーバー１５１の処理を低減しつつ、リソース別の権限制御を実現できる。特にリソースサーバー１５２において権限の絞り込み処理を実行し、認証・認可サーバー１５１では絞り込み済みの権限がスコープで要求された権限を満たすかを判定する。このため、認証・認可サーバー１５１はJWTに対応していれば、その権限検証手順を大幅に変更することなく、リソースサーバー１５２による処理によってリソース別のユーザー権限の付与を実現することができる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１５１ 認証・認可サーバー、１５２ リソースサーバー、３０３ 権限検証モジュール、３５１ リソースアクセス処理モジュール、３５２ リソース別ユーザー権限記憶モジュール

Claims (17)

1. リソースに対するアクセス権限を検証する権限検証システムであって、
   リソースごとに定めたリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、
   ユーザー権限を管理するユーザー権限管理手段と、
   指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定し、前記ユーザー権限管理手段で管理された前記ユーザー権限に基づいて、前記アクセス要求の送信元が有するユーザー権限を特定する特定手段と、
   前記特定手段で特定された前記指定されたリソースに対して有する権限で、特定された前記ユーザー権限を絞り込んでアクセス権限を決定する絞り込み手段と、
   前記絞り込み手段により絞り込まれた前記アクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるか判定する検証手段と、
   前記検証手段により前記アクセスが許可されると判定された場合には、前記送信元に、前記リソースに対するアクセスを許す手段と
   を有することを特徴とする権限検証システム。
2. 前記アクセス要求の送信元にユーザー権限を委譲して、委譲元のユーザーおよび委譲した権限を示すアクセストークンまたはジェイソンウエブトークンを発行する手段をさらに有し、
   前記アクセス要求の送信元が有するユーザー権限は、前記アクセストークンまたは前記ジェイソンウエブトークンにより示される、委譲された前記ユーザー権限であり、
   前記特定手段により特定される、前記指定されたリソースに対して有する権限は、前記ユーザー権限の委譲元のユーザーに関連付けられていることを特徴とする請求項１に記載の権限検証システム。
3. 前記絞り込み手段は、前記リソースに対して有する権限と、前記アクセス要求の送信元が有するユーザー権限とに共通する権限を、前記アクセス権限とすることを特徴とする請求項１または請求項２に記載の権限検証システム。
4. 前記絞り込み手段は、前記リソースに対して有する権限が空の場合には、前記アクセス権限を付与しないことを特徴とする請求項１または請求項２に記載の権限検証システム。
5. 前記絞り込み手段は、前記リソースに対して有する権限が空の場合には、前記アクセス要求の送信元が有するユーザー権限を前記アクセス権限とすることを特徴とする請求項１または請求項２に記載の権限検証システム。
6. 前記リソース別ユーザー権限に対する操作に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に、指定されたリソース別ユーザー権限を追加する手段と、
   前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限から、指定されたリソース別ユーザー権限を削除する手段とをさらに有することを特徴とする請求項１乃至５のいずれか一項に記載の権限検証システム。
7. 前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限から、特定のユーザーのリソース別ユーザー権限がすべて削除された場合には、前記ユーザー権限管理手段で管理された前記ユーザー権限から、前記特定のユーザーのユーザー権限を削除することを特徴とする請求項６に記載の権限検証システム。
8. 前記権限検証システムは、前記リソースに対するアクセス権限を検証する認証サーバーと、要求に応じて前記リソースに対するアクセスを提供するリソースサーバーとを含み、
   前記ユーザー権限管理手段は前記認証サーバーが有し、
   前記リソース別ユーザー権限管理手段は前記リソースサーバーが有することを特徴とする請求項１乃至請求項７のいずれか一項に記載の権限検証システム。
9. 前記絞り込み手段は前記認証サーバーが有することを特徴とする請求項８に記載の権限検証システム。
10. 前記絞り込み手段は前記リソースサーバーが有することを特徴とする請求項８に記載の権限検証システム。
11. リソースに対するアクセスを提供するリソースサーバーであって、
    リソースごとのリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、
    指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定する特定手段と、
    前記特定手段により特定した前記指定されたリソースに対して有する権限と、認証サーバーが有するユーザーごとのユーザー権限とに基づいたアクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるかの判定を認証サーバーに要求する手段と、
    前記認証サーバーからの応答に基づいて前記アクセスが許可されると判定された場合には、前記アクセス要求の送信元に、前記リソースに対するアクセスを許す手段と
    を有することを特徴とするリソースサーバー。
12. 前記リソースに対するアクセス要求とともに、前記アクセス要求の要求元に委譲されたユーザー権限を示すトークンを受信し、
    前記特定手段により特定した前記指定されたリソースに対して有する権限で、前記トークンに示されたユーザー権限を絞り込んで前記アクセス権限を決定する絞り込み手段をさらに有することを特徴とする請求項１１に記載のリソースサーバー。
13. 前記特定手段により特定した前記指定されたリソースに対して有する権限で、前記アクセス要求の送信元が有するユーザー権限を絞り込んでアクセス権限を決定する絞り込み手段をさらに有することを特徴とする請求項１１に記載のリソースサーバー。
14. リソースに対するアクセス権限を検証する認証サーバーであって、
    ユーザーごとのユーザー権限を管理するユーザー権限管理手段と、
    リソースに対するアクセス権限の判定の要求に応じて、該要求と共に受信したリソース別ユーザー権限と、前記ユーザー権限管理手段により管理された前記ユーザー権限とに基づいて、リソースに対するアクセスが許可されるか判定する検証手段と、
    前記検証手段による判定結果を前記要求の要求元に応答する手段と
    を有することを特徴とする認証サーバー。
15. リソースごとに定めたリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、ユーザー権限を管理するユーザー権限管理手段とを有する権限検証システムにおいて、リソースに対するアクセス権限を検証するための権限検証方法であって、
    指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定し、
    前記ユーザー権限管理手段で管理された前記ユーザー権限に基づいて、前記アクセス要求の送信元が有するユーザー権限を特定し、
    特定された前記指定されたリソースに対して有する権限で、特定された前記ユーザー権限を絞り込んでアクセス権限を決定し、
    前記アクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるか判定し、
    前記アクセスが許可されると判定された場合には、前記送信元に、前記リソースに対するアクセスを許すことを特徴とする権限検証方法。
16. リソースに対するアクセスを提供するリソースサーバーとしてコンピュータを機能させるためのプログラムであって、前記プログラムは、
    リソースごとのリソース別ユーザー権限を管理するリソース別ユーザー権限管理手段と、
    指定されたリソースに対するアクセス要求に応じて、前記リソース別ユーザー権限管理手段で管理された前記リソース別ユーザー権限に基づいて、前記指定されたリソースに対して有する権限を特定する特定手段と、
    前記特定手段により特定した前記指定されたリソースに対して有する権限と、認証サーバーが有するユーザーごとのユーザー権限とに基づいたアクセス権限で、前記アクセス要求に応じたリソースに対するアクセスが許可されるかの判定を認証サーバーに要求する手段と、
    前記認証サーバーからの応答に基づいて前記アクセスが許可されると判定された場合には、前記リソースに対してアクセスを許す手段と
    して前記コンピュータを機能させることを特徴とするプログラム。
17. リソースに対するアクセス権限を検証する認証サーバーとしてコンピュータを機能させるためのプログラムであって、前記プログラムは、
    ユーザーごとのユーザー権限を管理するユーザー権限管理手段と、
    リソースに対するアクセス権限の判定の要求に応じて、該要求と共に受信したリソース別ユーザー権限と、前記ユーザー権限管理手段により管理された前記ユーザー権限とに基づいて、リソースに対するアクセスが許可されるか判定する検証手段と、
    前記検証手段による判定結果を前記要求の要求元に応答する手段と
    して前記コンピュータを機能させることを特徴とするプログラム。

Images