JP2015095056A - 認可サーバーシステム、その制御方法、およびそのプログラム。 - Google Patents

Abstract

【課題】 ＡＰＩ利用量の上限に達しているにも関わらずクライアントのＡＰＩ利用を許してしまうとリソースサーバーに一定の負荷がかかってしまい、過剰な利用であった場合はリソースサーバーの品質が低下してしまう可能性が残る。
【解決手段】 認可サーバーと連携しＡＰＩ利用量の上限に達している場合に、ＯＡｕｔｈ２．０の権限委譲を制限する事でリソースサーバーの負荷軽減を図る。
【選択図】 図７

Description

クライアントにユーザーの権限を委譲する認可サーバーシステム、その制御方法、およびそのプログラム。

近年、インターネット上に展開された所謂クラウドサービスと呼ばれるＷｅｂサービスの利用が拡大している。例えば、ＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）サービスを利用して顧客関係を管理する形態や、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）を利用してリアルタイムに情報発信￥収集を行う形態である。クラウドサービスは個人だけでなく、ビジネスの現場でも拡大している。また、これら多数のクラウドサービスは各々がＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開しており、他のアプリケーションやクラウドサービスからＡＰＩを介してサービスを利用させる事が可能となっている。これを利用し、複数のクラウドサービスが公開するＡＰＩを別のクラウドサービスが利用し、あたかも一つのＷｅｂサービスのように構成するマッシュアップという機能が広がりつつある。

その一方で、複数のクラウドサービスを連携するマッシュアップ機能の利用機会の増加によっていくつかの課題が生まれる。それは、ユーザーが望んだ以上の情報が複数のクラウドサービス間で交換されユーザーデータや個人情報が漏えいするリスクである。本来、各クラウドサービスにて必要以上にユーザーデータ、個人情報等を取得することは望ましくなく、さらには、ユーザーが連携を望まないクラウドサービスに対してユーザーのデータおよび個人情報が提供されてはならない。しかし、サービスの提供者からするとクラウドサービス間の連携の仕組みは容易に実装できるものが好ましい。

このような状況における課題を解決するため、ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルが策定されている（非特許文献１を参照）。ＯＡｕｔｈ２．０によれば、例えばあるサービスＡが管理するユーザーのデータを取得するＡＰＩに対して、そのユーザーから認められたサービスＢがアクセスすることを許すプロトコルである。サービスＡは、サービスＢからアクセスされるリソースの範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。

ユーザーが認可操作を行うと、サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以降、認可トークンと称する）を受け取り、サービスＡのＡＰＩへのアクセスはその認可トークンを用いて実現できる。このユーザーの認可操作によってユーザーのリソースに対するアクセスを許可するための行為、即ちそのサービスにおけるユーザーの権限をサービスＢに委譲する行為を権限委譲と称する。

また、ＯＡｕｔｈ２．０ではサービスＢの成り済ましを防ぐためにサービスＢを認証する必要がある。サービスＢを認可するためには、サービスＡは予めサービスＢの認証情報、より具体的にはクライアントＩＤおよびシークレットを発行し、サービスＢにそれら認証情報を設定しておく必要がある。以降、サービスＡからみたサービスＢのことをクライアントと呼称する。更に、ＯＡｕｔｈ２．０では、上述のユーザーの認可操作、認可トークン発行、およびクライアントの認証を行う認可サーバーと、ユーザーのデータをリソースとして管理し、ＷｅｂサービスとしてＡＰＩを公開するリソースサーバーを分けて構成する事が可能である。その場合、サービスＢはユーザーからの権限委譲を受け、認可サーバーから認可トークンを取得し、その認可トークンを用いてリソースサーバーのＡＰＩを利用する。そして、リソースサーバーは、取得した認可トークンを認可サーバーに検証依頼し、結果、アクセスの許可を得られた場合にのみリソースへのアクセスを許可し、サービスＢにデータを応答するよう構成される。

その他の技術として、クライアントが利用するＡＰＩを単位時間あたりで監視することが知られている。これは、ある特定のクライアントから過剰にＡＰＩを利用されサービス全体の品質が低下してしまう事を防ぐためである。特に、サービスの利用量が課金される有償サービスでは、単位時間あたりの利用数に上限を設け、上限を超えたアクセスは拒否するよう構成される事が多い。これは、有償サービスは基本的に利用者との契約が行われる事で利用可能となり、有償サービスとしては契約した内容に従ったサービスを安定的に提供する責務を負うためである。例えば、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）と呼ばれるサービスの品質を保証する制度がよく知られている。このＳＬＡには、例えば、提供するサービスの最低速度や、利用不可能な時間の上限などが定義されている。ユーザーは、このＳＬＡに定義されているサービスの品質の対価として利用料金を支払う。また、ＳＬＡには、定義されている品質が守れなかった場合の処置としてサービス提供者側の罰則や、ユーザーへの保証、例えば利用料金の減額、が定義されている。よって、有償サービスでは、ＳＬＡに定義された品質を守る事が非常に重要となっており、ＡＰＩの利用量の上限設定、および上限を超えた場合にアクセスを拒否しサービスの品質低下を防ぐことが重要となる。

"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ"、［ｏｎｌｉｎｅ］ Ｄ． Ｈａｒｄｔ、２０１３年５月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞

しかしながら、例えばＯＡｕｔｈ２．０の構成の様にクライアントがユーザーの権限の委譲を受けて連携先のサーバーにアクセスするシステムにおいて、ＡＰＩの利用数の上限数を考慮し、クライアントに対して適切にＡＰＩを利用させる仕組みがなかった。
本発明の目的は、クライアントがユーザーの権限の委譲を受けて連携先のサーバーにアクセスするシステムにおいて、クライアントに対して適切にＡＰＩを利用させることにある。

本願発明の一実施形態に係る認可サーバーシステムは、ネットワークを介して提供されるサービスの利用を制限する認可サーバーシステムであって、ユーザーの前記サービスを利用する権限をクライアントへ委譲することを許可する認可操作が行われたことに応じて認可情報を発行する認可処理手段と、前記認可処理手段により発行された認可情報を取得した前記クライアントが前記ユーザーの権限で前記サービスを利用する際に送信する前記認可情報を検証し、当該検証の結果、前記クライアントに対し前記サービスの利用を許可する検証処理手段と、前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断する判断手段と、前記判断手段により超えていると判断された場合、前記関数の利用を制限する制限手段と、を有し、前記判断手段は、前記認可処理手段により前記認可情報が発行される際と、前記検証処理手段により前記認可情報が検証される際の両方のタイミングにおいて、前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断することを特徴とする

クライアントがユーザーの権限の委譲を受けて連携先のサーバーにアクセスするシステムにおいて、クライアントに対して適切にＡＰＩを利用させることが可能になる。

システム構成図。 各装置のハードウェア構成図。 各装置のソフトウェアモジュール構成図。 認可サーバーで管理するテーブル構造 認可サーバーで管理するテーブル構造 ＡＰＩ上限管理画面例 ＡＰＩ利用シーケンス 画面例 ＡＰＩ上限検証処理フロー ＡＰＩ通常上限検証処理フロー ＡＰＩ個別上限検証処理フロー 第二の実施例における認可サーバーで管理するテーブル構造 第二の実施例におけるＡＰＩ上限管理画面例 第二の実施例におけるＡＰＩ上限検証処理フロー

本願発明の実施例におけるクラウドサービスはマルチテナントという形態で提供される。マルチテナントとは、共有のサーバー上に展開した同一のＷｅｂアプリケーションを複数の企業や組織に提供する形態である。マルチテナントは、従来のサービス提供先の企業や組織ごとに専用のサーバーを用意して提供する形態よりコスト面で優れている。

ここで、前述のサービスＡがマルチテナントの形態であり、テナント１、テナント２の複数のテナントに所属するユーザーから利用されているとする。また、前述のサービスＢがクライアントとしてサービスＡが公開するＡＰＩを利用するとする。なお、前述のとおり、クライアントからのＡＰＩ利用については、単位時間あたりの利用数の上限が決まっている。その場合、以下のような課題が発生する。

サービスＢが、テナント１の所属ユーザーからの権限委譲によって発行された認可トークンを用いてＡＰＩを利用しＡＰＩ利用数が上限に達してしまった場合に、テナント２に所属するユーザーからの権限委譲によって発行された認可トークンを用いるとＡＰＩ利用が拒否されてしまう。つまり、ＳＬＡの内容によっては、テナント２所属のユーザーに対するＳＬＡが守れない可能性がある。この問題は、テナント毎にＡＰＩの上限数を設定されていなかったことに起因する。本願発明の実施例は、このようなクラウドサービスに対して特に有効な構成である。

では、始めに本願発明の各実施例にて用いられる用語の定義について説明する。サービスとは、サーバー上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能のことを指す。なお、そのソフトウェアであるＷｅｂアプリケーションのこともサービスと呼ぶ場合もある。本実施例においては、クラウドサービスとして連携サーバーが提供するサービスと、リソースサーバーが提供するサービスの２つのサービスがあり、ユーザーは、端末を介して連携サーバーが提供するサービスを利用している想定で説明している。また、リソースサーバーはサービスのＡＰＩを公開しており、連携サーバーはこのＡＰＩを利用する事でユーザーに対してマッシュアップ機能を提供している。つまり、リソースサーバーから見た場合、連携サーバーはクライアントに相当する。

なお、連携サーバーが、リソースサーバーのＡＰＩを利用するためには、後述するＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔによるユーザーの認可操作を伴った権限委譲が必要となる。言い換えると、ユーザーから権限委譲を受けた連携サーバーは、リソースサーバーのＡＰＩを利用する事ができるようになる。また、リソースサーバーが提供するサービス品質を確保するために、クライアントである連携サーバーに対して単位時間あたりのＡＰＩ利用数が管理されている。ここで、単にリソースサーバーにてＡＰＩ利用数をカウントし上限に達しているかを検証する構成では、連携サーバーから過剰にＡＰＩ利用が行われるとリソースサーバーの負荷が軽減されない課題が発生する。そこで、本願発明では、認可サーバーと連携し、ＯＡｕｔｈ２．０の権限委譲を制限する事で、リソースサーバーの負荷軽減を図る。詳細については後述する。

ＡＰＩとは、サービスを利用するために呼び出すための関数を指す。呼び出し元であるクライアントがＡＰＩをコールすることでサービスを受けられ、ユーザーからはあたかもそのクライアントが処理を行ったかのように見える。以下、本発明を実施するための最良の形態について図面を用いて説明する。

本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。

２００はＯＡｕｔｈ２．０を実現するための認可サーバーであり、認可サーバーモジュールが設置されている。３００はリソースサーバーであり、Ｗｅｂサービスとして公開されるＡＰＩを備えるリソースサーバーモジュールが設置されている。４００は連携サーバーであり、連携サーバーモジュールが設置されている。連携サーバーモジュールは、リソースサーバー３００が備えるリソースサーバーモジュールが公開するＡＰＩを利用する事で、自身が提供するサービスと合わせてマッシュアップ機能をユーザーに提供する。５００はデータベースサーバーであり、認可サーバー２００とＬＡＮ１０１を介して接続しており、認可サーバーモジュールが利用するデータが格納されている。８１０は端末であり、Ｗｅｂブラウザー８２０が設置されている。例えば、ＰＣやスマートフォンと呼ばれる携帯端末等である。

ユーザーはＷｅｂブラウザー８２０を用いて連携サーバー４００、認可サーバー２００と通信する。また認可サーバー２００、リソースサーバー３００はＬＡＮ１０１を介して接続されている。また、認可サーバー２００、リソースサーバー３００、連携サーバー４００、および端末８１０は、それぞれＷＡＮ１００を介して通信可能に接続されている。また認可サーバー２００、データベースサーバー５００は同一のサーバー上に構成されていてもよい。なお、本実施例における各サーバーは１台で構成されているが複数台から構成されたサーバー群であっても良い。そこで、本実施例ではそのようなサーバーをサーバーシステムと称する。例えば、認可サーバーシステムと称した場合、１台で構成される認可サーバー、および複数台で構成される認可サーバー群の両方を指していることになる。

本実施の形態に係る権限委譲システムは、図２に示すような構成のサーバーおよび端末から成るシステム上に実現される。図２は、認可サーバー２００、リソースサーバー３００、連携サーバー４００、端末８１０、およびデータベースサーバー５００のハードウェア構成を示す。なお、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバーおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。

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

図３は本実施の形態に係る認可サーバー２００、リソースサーバー３００、連携サーバー４００それぞれのモジュール構成を示す図である。なお認可サーバー２００、リソースサーバー３００、連携サーバー４００は図２のものと同一である。図中２００は認可サーバー２００である。認可サーバー２００は認可サーバーモジュール６００、ＨＴＴＰサーバーモジュール６１０を持つ。ＨＴＴＰサーバーモジュール６１０はＷＡＮ１００を介して接続する端末８１０に設置されたＷｅｂブラウザー８２０とのＨＴＴＰ通信を行うためのモジュールである。また、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施例では、後述する認可要求を受け付けた場合に、要求元に対してユーザーＩＤ、パスワードによるユーザー認証を要求するよう構成している。

次に、認可サーバーモジュール６００はＨＴＴＰサーバーモジュール６１０を介してＷｅｂブラウザー８２０からの要求を受け付け、処理し、応答する。その際、本実施例では、ＨＴＴＰサーバーモジュール６１０にてユーザー認証を受け付け、要求元の認証に成功した場合、認証したユーザー情報を紐づけた認証トークンを生成し認可サーバーモジュール６００に通知するよう構成されている。ここで、認証トークンとはユーザーを認証しログインしている事を示す、もしくは認証されているかを検証するためのトークンであり、この認証トークンを利用する事でユーザーを識別する事が可能となる。

一方、後述の認可トークンは、認証されたユーザーが認可操作をおこなった際に、対象となるクライアントがユーザーの権限をもってユーザーに成り代わってアクセスを許可する事を示すためのトークンであり、両者は異なる。さらには、認可トークンは、認可コードを用いて取得し、クライアントがＡＰＩを利用するための権限を持つことを示すトークンである。認可トークンの様にユーザーのサービスを利用する権限をクライアントへ委譲されたことを示す情報を認可情報と称する。

ＨＴＴＰサーバーモジュール６１０、および認可サーバーモジュール６００における処理の詳細は後述する。認可サーバーモジュール６００はＬＡＮ１０１を介してリソースサーバーモジュール７００からの認可トークン検証処理を受け付け、処理し、応答するよう構成されている。この認可トークン検証処理は、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）として構成する事も可能であるし、ＨＴＴＰサーバーモジュール６１０を介してＬＡＮ１０１内で通信可能なＷｅｂサービスのＡＰＩとして構成する事も可能である。

図中３００はリソースサーバー３００である。リソースサーバー３００はリソースサーバーモジュール７００を持つ。リソースサーバーモジュールは不図示のＨＴＴＰサーバーモジュール上で動作するよう構成する事も可能である。リソースサーバーモジュール７００はＷｅｂサービスとして公開するＡＰＩを備えており、後述する連携サーバー４００からのリソース要求を受け付け、処理し、応答する。また、リソースサーバーモジュール７００は認可サーバーモジュール６００に対してＬＡＮ１０１を介して後述の認可トークン検証処理を要求する。

図中４００は連携サーバー４００である。連携サーバー４００は連携サーバーモジュール８００を持つ。連携サーバーモジュール８００は不図示のＨＴＴＰサーバーモジュール上で動作するよう構成する事も可能である。連携サーバーモジュール８００はＷｅｂアプリケーションであり、Ｗｅｂブラウザー８２０からの要求を受け付け、処理し、応答する。また、連携サーバーモジュール８００は、リソースサーバーモジュール７００が公開するＷｅｂサービスのＡＰＩを呼び出すＨＴＴＰクライアントとしても構成されている。

図４ａ、図４ｂ、図４ｃは認可サーバー２００がＬＡＮ１０１を介して通信可能に構成されたデータベースサーバー５００（不図示）の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリに構成する事もできる。図４ａはユーザー管理テーブル１２００である。ユーザー管理テーブル１２００は、ユーザーＩＤ１２０１、パスワード１２０２、テナントＩＤ１２０３、および種別１２０４から成る。認可サーバー２００は、ユーザーＩＤ１２０１、パスワード１２０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザーを認証する機能を備える。

テナントＩＤ１２０３は各ユーザーＩＤにて識別されるユーザーが所属するテナントのＩＤである。テナントとはユーザーが属する企業を特定するための単位であり、テナントＩＤからそのユーザーが属する企業が判別できる。本実施例ではテナントを例に説明を行うが、テナントに限らず特定のグループ単位でユーザーを管理し、グループＩＤからそのユーザーが属するグループを特定する形態であればどのようなグループ単位であっても良い。種別１２０４は各ユーザーＩＤにて識別されるユーザーの権限を示す。種別１２０４が［クライアント管理者］である場合は、後述のＡＰＩ上限管理画面にて、クライアントのＡＰＩの上限数について確認、設定する事ができる。この種別１２０４が［クライアント管理者］であるユーザーＩＤ１２０１、パスワード１２０２は、連携サーバー４００を管理しているか、もしくは管理が委譲されたユーザーに予め通知されている。また、種別１２０４が［ユーザー］である場合は、後述のシーケンスにてクライアントに権限委譲する事ができる。この種別１２０４が［ユーザー］であるユーザーＩＤ１２０１、パスワード１２０２は、端末８１０の利用者に予め通知されている。各処理の詳細については後述する。

図４ｂはクライアント管理テーブル１３００である。クライアント管理テーブル１３００はクライアントＩＤ１３０１、シークレット１３０２、テナントＩＤ１３０３、リダイレクトＵＲＬ１３０４、クライアント名１３０５から成る。認可サーバー２００は、クライアントＩＤ１３０１、シークレット１３０２の情報の組を検証し、正しければ認証情報を生成することで、各クライアントを認証する機能を備える。また、クライアントＩＤ１３０１、シークレット１３０２の組は、予め連携サーバーモジュール８００に設定されている。ここで、リダイレクトＵＲＬとは、後述するＯＡｕｔｈ２．０におけるＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローにおいて、認可サーバー２００が、ユーザーがクライアントに対して権限を委譲する事を許可した事を示す認可コードをクライアントが受け取るためのクライアントのＵＲＬである。本実施例では、連携サーバーモジュール８００が、認可サーバーモジュール６００が発行した認可コードを受け付けるための連携サーバーモジュール８００のＵＲＬとなる。リダイレクトＵＲＬ１３０４、クライアント名１３０４は、クライアントＩＤ１３０１、シークレット１３０２を生成する際に取得し、登録される。本実施例では、このクライアントＩＤ１３０１、シークレット１３０２と、リダイレクトＵＲＬ１３０４、クライアント名１３０５は、予め連携サーバー４００を用いてクラウドサービスを展開している事業者と、認可サーバー２００を用いてクラウドサービスを展開している事業者間での取り決めにより授受しているものとして説明する。

しかしながら、例えば、クライアントの発行画面を認可サーバーモジュール８００が備え、連携サーバー４００の管理者が当該画面にアクセスし、情報の授受を行うよう構成する事も可能である。テナントＩＤ１３０３は、ユーザー管理テーブル１２００のテナントＩＤ１２０３と関係があり、同じテナントＩＤであった場合はそのクライアントＩＤにて識別されるクライアントの［クライアント管理者］ユーザーである事が特定される。つまり、同一テナントＩＤの［クライアント管理者］ユーザーにて、クライアントＩＤにて識別されるクライアントのＡＰＩの上限数について確認、設定が行われる。これら処理、およびリダイレクトＵＲＬ１３０４、クライアント名１３０５の処理の詳細については後述する。

図４ｃは認可トークン管理テーブル１４００である。認可トークン管理テーブル１４００は、認可トークンＩＤ１４０１、トークン種別１４０２、有効期限１４０３、クライアントＩＤ１４０４、ユーザーＩＤ１４０５から成る。認可トークン管理テーブル１４００の詳細については後述する。

図５ａ、図５ｂ、図５ｃ、図５ｄは認可サーバー２００がＬＡＮ１０１を介して通信可能に構成されたデータベースサーバー５００の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリに構成する事もできる。

図５ａはＡＰＩ利用数上限管理テーブル１５００である。ＡＰＩ利用数上限管理テーブル１５００は、クライアントＩＤ１５０１、上限値１５０２、リセット時刻１５０３、期間１５０４、上限時モード１５０５、期間あたりのコール数１５０６から成る。本実施例では、上限値１５０２、リセット時刻１５０３、期間１５０４の設定値は、予め連携サーバー４００を用いてクラウドサービスを展開している事業者と、リソースサーバー３００を用いてクラウドサービスを展開している事業者間での取り決めにより設定されているとして説明する。なお、不図示の事業者間の契約を管理するための画面を設け、認可サーバーモジュール６００に構成し、連携サーバー４００の管理者がＷｅｂブラウザー８２０を用いて当該画面にアクセスし、設定を行えるよう構成する事も可能である。これらＡＰＩ利用数上限管理テーブル１５００の詳細については後述する。また、期間あたりのコール数１５０６は、期間１５０４の間隔にて、リセット時刻１５０３の時刻に０回にリセットされるよう構成されている。

図５ｂはテナント個別設定管理テーブル１６００である。テナント個別設定管理テーブル１６００は、クライアントＩＤ１６０１、テナント個別拒否設定１６０２、テナント個別許可設定１６０３、テナント個別上限値合計１６０４から成る。これらテナント個別設定管理テーブル１６００の詳細については後述する。

図５ｃはテナント個別拒否設定管理テーブル１７００である。テナント個別拒否設定管理テーブル１７００は、クライアントＩＤ１７０１、拒否テナントＩＤ１７０２から成る。これらテナント個別拒否設定管理テーブル１７００の詳細については後述する。

図５ｄはテナント個別許可設定管理テーブル１８００である。テナント個別許可設定管理テーブル１８００は、クライアントＩＤ１８０１、許可テナントＩＤ１８０２、上限値１８０３、期間あたりのコール数１８０４から成る。許可テナントＩＤ１８０２と上限値１８０３は関連付けられて登録されており、許可テナントＩＤが特定されるとそのテナントに対して割り当てられている上限値を特定することができる。なお、グループＩＤ毎、即ちテナントＩＤ毎に上限値が設定される。これらテナント個別許可設定管理テーブル１８００の詳細については後述する。なお、期間あたりのコール数１８０４は、ＡＰＩ利用数上限管理テーブル１５００の期間１５０４の間隔にて、リセット時刻１５０３の時刻に０回にリセットされるよう構成されている。

図６ａ、図６ｂ、図６ｃは認可サーバーモジュール６００が生成するクライアントのＡＰＩ利用数の上限値を管理、設定するための上限管理画面例である。この画面は、連携サーバー４００の管理者か、もしくは管理を委譲されているユーザーが利用するＷｅｂブラウザー８２０に表示される画面である。

図６ａは、クライアントのＡＰＩの上限数を確認、設定するためのＡＰＩ利用数上限管理画面２０００である。ＡＰＩ利用数上限管理画面２０００は、上限値２００１、上限値設定２００２、テナント個別拒否設定ボタン２００３、テナント個別許可設定ボタン２００４、設定ボタン２００５、閉じるボタン２００６から構成される。以下、図６ａ、図８ａを用いてＡＰＩ利用数上限管理画面２０００の処理について説明する。なお、閉じるボタン２００６を押下された場合、Ｗｅｂブラウザー８２０は当該画面を閉じ、処理を終了する。

連携サーバー４００の管理者かもしくは管理を委譲されているユーザーは、Ｗｅｂブラウザー８２０を用いて、ＨＴＴＰサーバーモジュール６１０にアクセスする。ＨＴＴＰサーバーモジュール６１０はＷｅｂブラウザー８２０からのアクセスを受けると、Ｗｅｂブラウザー８２０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。含まれている場合、ＨＴＴＰサーバーモジュール６１０は、認証トークンを認可サーバーモジュール６００に通知する。含まれていない場合は、以下の処理を実行する。ＨＴＴＰサーバーモジュール６１０は、ユーザー認証をするためにログイン画面をＷｅｂブラウザー８２０に応答する。ここで図８ａはＨＴＴＰサーバーモジュール６１０が応答するログイン画面例である。本実施例ではユーザーはユーザーＩＤおよびパスワードを入力し、それらの組がユーザー管理テーブル１２００に登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザーを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。

図８ａは、ユーザーＩＤを入力するユーザーＩＤ入力欄３００１、パスワードを入力するパスワード入力欄３００２、およびログイン操作を実行するためのログインボタン３００３から成る。ユーザーはＷｅｂブラウザー８２０に表示された図８ａに必要な情報を入力し、ログインボタン３００３を押下する。Ｗｅｂブラウザー８２０は入力された情報をＨＴＴＰサーバーモジュール６１０に送信する。ＨＴＴＰサーバーモジュール６１０はユーザーＩＤ、パスワードを取得し、ユーザー管理テーブル１２００のユーザーＩＤ１２０１、パスワード１２０２の情報の組と比較し一致するかを検証する事でユーザーを認証する。さらに、ユーザー管理テーブル１２００にて、認証したユーザーＩＤ１２０２の種別１２０４が［クライアント管理者］であるかを確認する。ＨＴＴＰサーバーモジュール６１０は、ユーザー認証に失敗、つまり、ユーザー管理テーブル１２００に、取得した情報が登録されていないか、もしくは種別１２０４が［クライアント管理者］でない場合は、不図示の認証エラー画面をＷｅｂブラウザー８２０に応答する。ユーザー認証に成功した場合、ＨＴＴＰサーバーモジュール６１０は認証トークンを生成する。

この認証トークンはＨＴＴＰサーバーモジュール６１０の不揮発メモリ上に、ユーザーＩＤ１２０１、テナントＩＤ１２０３と対応付けて保存される。そして、ＨＴＴＰサーバーモジュール６１０は、認証トークンを認可サーバーモジュール６００に通知する。なお、この認証トークンはＨＴＴＰ Ｃｏｏｋｉｅとして設定され、ＨＴＴＰサーバーモジュール６１０からＷｅｂブラウザー８２０への応答に設定され通知される。換言すれば、認証トークンをＷｅｂブラウザー８２０がＨＴＴＰサーバーモジュール６１０に送信することで、ユーザーはＷｅｂブラウザー８２０を介してユーザーＩＤ、パスワードを入力することなく認可サーバーモジュール６００へのアクセスが可能になる。以後、Ｗｅｂブラウザー８２０から認可サーバーモジュール６００へのアクセスは上記のとおり、ＨＴＴＰサーバーモジュール６１０による認証トークンの検証、認証処理、および認証トークンの認可サーバーモジュール６１０への通知が実行されるとして説明を省略する。なお、認証トークンは後述する認可コード、および認可トークンとは異なるものであることに留意されたい。

認証トークンを受け付けた認可サーバーモジュール６００は、認証トークンに紐づいたテナントＩＤ１２０３の値を取得し、同じテナントＩＤが、クライアント管理テーブル１３００のテナントＩＤ１３０３に設定されているクライアントＩＤ１３０１を特定する。そして、特定したクライアントＩＤに対するＡＰＩの上限数の確認、設定するための画面であるＡＰＩ利用数上限管理画面２０００を生成し、Ｗｅｂブラウザー８２０に応答する。以後、認可サーバーモジュール６００にて同様に行われる、通知された認証トークンを用いたクライアントＩＤの特定処理についての説明は省略する。

次に、認可サーバーモジュール６００でのＡＰＩ利用数上限管理画面２０００の生成処理について説明する。認可サーバーモジュール６００は、ＡＰＩ利用数上限管理テーブル１５００から、特定したクライアントＩＤがクライアントＩＤ１５０１に設定されている各項目の情報を取得する。認可サーバーモジュール６００は、取得した上限値１５０２、リセット時刻１５０３、期間１５０４を用いて、上限値２００１を生成する。さらに、認可サーバーモジュール６００は、テナント個別設定管理テーブル１６００から、特定したクライアントＩＤがクライアントＩＤ１６０１に設定されている各項目の情報を取得する。認可サーバーモジュール６００は、取得したテナント個別拒否設定１６０２、テナント個別許可設定１６０３、テナント個別上限値合計１６０４を用いて、上限値２００１、および上限値設定２００２を生成する。なお、図６ａのＡＰＩ利用数上限管理画面２０００は特定したクライアントＩＤが［ｃｌｉｅｎｔ＿００１］であった場合の画面例を示している。

次に、ＡＰＩ利用数上限管理画面２０００において、各種ボタンを押下した場合の処理について説明する。テナント個別拒否設定ボタン２００３は、テナント個別拒否設定にて［設定する］を選択している場合にのみ押下可能なボタンである。テナント個別拒否設定ボタン２００３を押下した場合、認可サーバーモジュール６００は図６ｂで示すテナント個別拒否設定画面２１００を生成し、応答する。テナント個別拒否設定画面２１００については後述する。テナント個別許可設定ボタン２００４は、テナント個別許可設定にて［設定する］を選択している場合にのみ押下可能なボタンである。テナント個別許可設定ボタン２００４を押下した場合、認可サーバーモジュール６００は図６ｃで示すテナント個別許可設定画面２２００を生成し、応答する。テナント個別許可設定画面２２００については後述する。設定ボタン２００５は、ＡＰＩ上限値設定２２００の各項目の選択状態を設定、反映するためのボタンである。設定ボタン２００５が押下された場合、上限に達した場合の動作、テナント個別拒否設定、テナント個別許可設定の各選択状態が、Ｗｅｂブラウザー８２０から認可サーバーモジュール６００に通知される。

通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤを用いてクライアント上限管理テーブル１５００の上限時モード１５０５に対して通知された上限に達した場合の動作の選択状態を反映する。さらに、認可サーバーモジュール６００は、特定したクライアントＩＤを用いてテナント個別設定管理テーブル１６００のテナント個別拒否設定１６０２に対して、テナント個別拒否設定の選択状態、および、テナント個別許可設定１６０３に対して、テナント個別許可設定の選択状態を反映する。認可サーバーモジュール６００は各反映されたデータを用いて、ＡＰＩ利用数上限管理画面２０００をＷｅｂブラウザー８２０に応答する。

図６ｂはテナント個別拒否設定画面２１００である。テナント個別拒否設定画面２１００は拒否するテナントの登録２１０１、登録ボタン２１０２、拒否するテナント一覧２１０３、解除ボタン２１０４、および閉じるボタン２１０５から構成される。以下、図６ｂを用いてテナント個別拒否設定画面２１００の処理について説明する。なお、閉じるボタン２１０５を押下された場合、Ｗｅｂブラウザー８２０は当該画面を閉じ、処理を終了する。

認可サーバーモジュール６００は、ＡＰＩ利用数上限管理画面にて、テナント個別拒否設定ボタン２００３を押下されると、特定したクライアントＩＤを用いて、テナント個別拒否設定テーブル１７００から０個以上の拒否テナントＩＤ１７０２を取得し、テナント個別拒否設定画面２１００を生成する。登録ボタン２１０２は拒否するテナントを追加登録する際に押下するボタンである。登録ボタン２１０２を押下された場合、Ｗｅｂブラウザーは拒否するテナントの登録２１０１に入力されたテナントＩＤを認可サーバーモジュール６００に通知する。通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤおよび、通知されたテナントＩＤをテナント個別拒否設定テーブル１７００に設定する。解除ボタン２１０４は拒否するテナントから解除する際に押下するボタンである。解除ボタン２１０４を押下された場合、Ｗｅｂブラウザーは、解除ボタン２１０４に対応する拒否するテナント一覧２１０３に表示しているテナントＩＤを認可サーバーモジュール６００に通知する。通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤおよび、通知されたテナントＩＤの組を、テナント個別拒否設定テーブル１７００から削除する。なお、図６ｂのテナント個別拒否設定画面２１００は特定したクライアントＩＤが［ｃｌｉｅｎｔ＿００１］であった場合の画面例を示している。

図６ｃはテナント個別許可設定画面２２００である。テナント個別許可設定画面２２００は個別設定するテナントの登録・変更２２０１、登録・変更ボタン２２０２、個別設定テナント一覧２２０３、解除ボタン２２０４、および閉じるボタン２２０５から構成される。以下、図６ｃを用いてテナント個別許可設定画面２２００の処理について説明する。なお、閉じるボタン２２０５を押下された場合、Ｗｅｂブラウザー８２０は当該画面を閉じ、処理を終了する。

認可サーバーモジュール６００は、ＡＰＩ利用数上限管理画面にて、テナント個別許可設定ボタン２００４を押下されると、特定したクライアントＩＤを用いて、テナント個別許可設定テーブル１８００から０個以上の許可テナントＩＤ１８０２、上限値１８０３、および、クライアント上限管理テーブル１５００から期間１５０４を取得し、テナント個別許可設定画面２１００を生成する。登録・変更ボタン２２０２は個別設定するテナントを追加登録、もしくは上限値を変更する際に押下するボタンである。登録・変更ボタン２２０２を押下された場合、Ｗｅｂブラウザーは個別設定するテナントの登録・変更２２０１に入力されたテナントＩＤ、および上限値を認可サーバーモジュール６００に通知する。通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤ、通知されたテナントＩＤ、および上限値をテナント個別許可設定テーブル１８００に設定する。その際、クライアントＩＤとテナントＩＤの組が既に設定済みであった場合は、その組に対する上限値１８０３の値を更新する。さらに、テナント個別設定管理テーブル１６００のテナント個別上限値合計１６０４を再計算し、更新する。解除ボタン２２０４は個別設定するテナントから解除する際に押下するボタンである。解除ボタン２２０４を押下された場合、Ｗｅｂブラウザーは、解除ボタン２２０４に対応する個別設定テナント一覧２２０３に表示しているテナントＩＤを認可サーバーモジュール６００に通知する。通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤおよび、通知されたテナントＩＤの組および、上限値を、テナント個別許可設定テーブル１８００から削除する。なお、図６ｃのテナント個別許可設定画面２２００は特定したクライアントＩＤが［ｃｌｉｅｎｔ＿００１］であった場合の画面例を示している。

なお、図６ａ、図６ｂ、図６ｃは夫々独立した画面として提供されるものとして説明を行ったが、全てを１つの画面にまとめた形態であっても良い。また、図６ａでは、テナント個別許可設定、およびテナント個別拒絶設定の両方が設定できる画面を示したが、少なくとも何れか１方が設定出来る画面であっても良い。本実施例では、テナントＩＤを指定し、指定されたテナントＩＤに対し関数を呼び出す際の上限値を設定出来るような画面を管理画面と称す。管理画面と称した場合、図６ａ、図６ｂ、図６ｃの設定を設定することが可能な画面と言うことになる。

次に、図７、図８ａ、図８ｂ、および図８ｃを用いて、連携サーバーモジュール８００が、リソースサーバーモジュール７００が公開するＡＰＩを利用するまでの、本実施形態のシーケンスを説明する。なお、図中“Ｒｅｆ”は参照を示しており、別図で説明する。また、“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Ｏｐｔ”は上限を満たした場合にのみ処理を実行する事を示す。

Ｓ１．１にてユーザーはＷｅｂブラウザー８２０に表示されている不図示の連携開始操作を実行する。Ｓ１．２にてＷｅｂブラウザー８２０から連携サーバーモジュール８００に連携開始が通知される。連携開始を受けた連携サーバーモジュール８００は、Ｓ１．３にてＷｅｂブラウザー８２０、ＨＴＴＰサーバーモジュール６１０を介して認可サーバーモジュール６００に対して認可要求を行う。ここで、Ｓ１．３の認可要求からＳ３．２の認可トークン応答までの認可トークンの発行処理はＯＡｕｔｈ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローに従って実施される。

なお、認可要求には、少なくとも、連携サーバーモジュール８００が保持しているクライアントＩＤおよびリダイレクトＵＲＬが含まれ、連携サーバーモジュール８００がユーザーから委譲された権限でリソースサーバーモジュール７００にアクセスするために必要な認可コードの発行の依頼も含まれる。なお、リダイレクトＵＲＬは前述したとおり、認可サーバー２００にて発行された認可コードを受け付けるためのクライアントのＵＲＬである。

Ｓ１．４にて、Ｗｅｂブラウザー８２０から認可要求を受け付けたＨＴＴＰサーバーモジュールは、Ｗｅｂブラウザー８２０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか否かを検証する。含まれている場合、ＨＴＴＰサーバーモジュール６１０は認証トークンを認可サーバーモジュール６００に通知しＳ１．９に移行する。含まれていない場合は、Ｓ１．５の処理を実行する。

Ｓ１．５にて、ＨＴＴＰサーバーモジュール６１０は、ユーザー認証をするためにログイン画面をＷｅｂブラウザー８２０に応答する。ここで図８ａはＨＴＴＰサーバーモジュール６１０が応答するログイン画面である。本実施例ではユーザーはユーザーＩＤおよびパスワードを入力し、それらの組がユーザー管理テーブル１２００に登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザーを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。

図８ａは、ユーザーＩＤを入力するユーザーＩＤ入力欄３００１、パスワードを入力するパスワード入力欄３００２、およびログイン操作を実行するためのログインボタン３００３から成る。ユーザーはＷｅｂブラウザー８２０に表示された図８ａに必要な情報を入力し、ログインボタン３００３を押下する。Ｗｅｂブラウザー８２０は入力された情報をＨＴＴＰサーバーモジュール６１０に送信する。ＨＴＴＰサーバーモジュール６１０はユーザーＩＤ、パスワードを取得し、ユーザー管理テーブル１２００のユーザーＩＤ１２０１、パスワード１２０２の情報の組と比較し一致するかを検証する事でユーザーを認証する。さらに、ユーザー管理テーブル１２００にて、認証したユーザーＩＤ１２０２の種別１２０４が［ユーザー］であるかを確認する。ＨＴＴＰサーバーモジュール６１０は、ユーザー認証に失敗、つまり、ユーザー管理テーブル１２００に、取得した情報が登録されていないか、もしくは種別１２０４が［ユーザー］でない場合は、不図示の認証エラー画面をＷｅｂブラウザー８２０に応答する。

ユーザー認証に成功した場合、ＨＴＴＰサーバーモジュール６１０は認証トークンを生成する。この認証トークンはＨＴＴＰサーバーモジュール６１０の不揮発メモリ上に、ユーザーＩＤ１２０１、テナントＩＤ１２０３と対応付けて保存される。そして、ＨＴＴＰサーバーモジュール６１０は、認証トークンを認可サーバーモジュール６００に通知する。なお、この認証トークンはＨＴＴＰ Ｃｏｏｋｉｅとして設定され、ＨＴＴＰサーバーモジュール６１０からＷｅｂブラウザー８２０への応答に設定され通知される。以後、Ｗｅｂブラウザー８２０から認可サーバーモジュール６００へのアクセスは上記のとおり、ＨＴＴＰサーバーモジュール６１０による認証トークンの検証、認証処理、および認証トークンの認可サーバーモジュール６１０への通知が実行されるとして説明を省略する。

Ｓ１．９にて、認証トークンを含む認可要求を受け付けた認可サーバーモジュール６００は、Ｓ１．１０にて、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＬの組が正しいか検証する。より具体的には、クライアント管理テーブル１３００に登録されているクライアントＩＤ１３０１とリダイレクトＵＲＬ１３０４の組が一致するか検証する。不一致の場合、認可サーバーモジュール６００は不図示のエラー画面を、ＨＴＴＰサーバーモジュール６１０を介してＷｅｂブラウザー８２０に応答する。一致した場合、認可サーバーモジュール６００はＳ１．１１にてＡＰＩ上限検証処理を実行する。この際、ＨＴＴＰサーバーモジュール６１０から通知された認証トークンから取得したユーザーＩＤ、および、認可要求として受信したクライアントＩＤを用いて処理を実行する。ＡＰＩ上限検証処理の詳細については後述する。

ＡＰＩ上限検証処理の結果が［拒否応答］である場合は、認可サーバーモジュール６００はＳ２．１１、Ｓ２．１２にて、Ｗｅｂブラウザー８２０を介して連携サーバーモジュール８００に対して権限エラーを応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＬに対してＷｅｂブラウザー８２０をリダイレクトするようＷｅｂブラウザー８２０にリダイレクト応答する。Ｓ２．１３にて連携サーバーモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。なお、図８ｃに示した画面は一例であり、例えば、連携サーバーモジュール８００がエラー応答の内容を認識できるのであれば、権限に関するエラー内容のみを表示する画面、またはＡＰＩの利用数の上限に達したことを通知する画面のように切り替えて表示しても良い。ここまでの一連の処理により、ＡＰＩの利用数が既に上限に達していた場合に、連携サーバーモジュール８００からリソースサーバーモジュール７００へのアクセスをすることなく、処理を終了する事ができる。結果的に、リソースサーバーモジュール７００の負荷を軽減する事ができる。

次に、ＡＰＩ上限検証処理の結果が［許可応答］である場合は、認可サーバーモジュール６００はＳ２．１にて、Ｗｅｂブラウザー８２０に対して認可確認画面を応答する。図８ｂは応答される認可確認画面である。認可確認画面３１００は、認可要求に含まれるクライアントＩＤをキーとしてクライアント管理テーブル１３００から取得したクライアント名１３０５を表示する領域であるアクセス元表示領域３１０１を備える。また、認可確認画面３１００は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン３１０２、および拒否を実行する拒否ボタン３１０３を備える。ここで、ユーザーが拒否ボタン３１０３を押下した場合は、認可サーバーモジュール６００は、ＡＰＩ上限検証処理の結果が［拒否応答］であった場合と同様にＳ２．１１、Ｓ２．１２にて連携サーバーモジュール８００に権限エラーを応答する。なお、これら権限エラー応答については、応答を受け付ける連携サーバーモジュール８００にて表示する画面の構成、もしくは文言を変更するために、エラー応答の内容を区別可能に構成する事も可能である。

Ｓ２．２にてユーザーが認可確認画面３１００にて、許可ボタン３１０２を押下、つまりユーザーのリソースサーバー３００が提供するサービスにおける権限を、連携サーバー４００に委譲することを許可する認可操作を行った場合、Ｗｅｂブラウザー８２０を介し、Ｓ２．３にて認可サーバーモジュール６００に認可した事が通知される。

Ｓ２．４にて認可サーバーモジュール６００は、認可コードを発行する。より具体的には、認可トークンＩＤを発行し、認可要求に含まれるクライアントＩＤ、許可を得たユーザーのユーザーＩＤを認可トークン管理テーブル１４００に登録する。その際、トークン種別１４０２は認可コードとし、有効期限１４０３に当該認可コードが有効である日時を登録する。そして、Ｓ２．５、Ｓ２．６にて認可サーバーモジュール６００は発行した認可コードの認可トークンＩＤを付与してＷｅｂブラウザー８２０を介し、連携サーバーモジュール８００に認可を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＬに対してＷｅｂブラウザー８２０をリダイレクトするようＷｅｂブラウザー８２０にリダイレクト応答する。

Ｓ２．７にて連携サーバーモジュール８００は、認可サーバーモジュール６００に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、クライアントＩＤ、シークレット、および認可要求時に送信したリダイレクトＵＲＬが含まれる。

Ｓ２．８にて認可サーバーモジュール６００は取得したクライアントＩＤ、シークレットの組をもってクライアントを認証する。より具体的には、クライアント管理テーブル１３００のクライアントＩＤ１３０１、シークレット１３０２の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合は連携サーバーモジュール８００に認証エラーを応答する。クライアント認証に成功した場合、Ｓ２．９にて認可サーバーモジュール６００は、取得した認可コードを検証する。認可コードの検証としては、取得した認可コードの認可トークンＩＤが認可トークン管理テーブル１４００に登録されているか否かを検証する。登録されている場合、認可サーバーモジュール６００は有効期限１４０３の範囲内か否かを検証する。さらには、認可トークン要求にて取得したリダイレクトＵＲＬが、認可トークンＩＤに紐づくクライアントＩＤ１４０４をキーとしてクライアント管理テーブル１３００に登録されているリダイレクトＵＲＬ１３０４と一致するかを検証する。認可コード検証の結果が無効であった場合、認可サーバーモジュール６００は連携サーバーモジュール８００にトークン不正エラーを応答する。そして、認可コード検証の結果が有効であった場合、認可サーバーモジュール６００はＳ２．１０にてＡＰＩ上限検証処理を実行する。この際、認可コードに紐づくユーザーＩＤ、および、認証したクライアントＩＤを用いて処理を実行する。ＡＰＩ上限検証処理の詳細については後述する。ＡＰＩ上限検証処理の結果が［拒否応答］である場合は、認可サーバーモジュール６００はＳ３．９にて、連携サーバーモジュール８００に対して権限エラーを応答する。Ｓ３．１０にて連携サーバーモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。

ここまでの一連の処理により、ＡＰＩの利用数が既に上限に達していた場合に、連携サーバーモジュール８００からリソースサーバーモジュール７００へのアクセスをすることなく、処理を終了する事ができる。結果的に、リソースサーバーモジュール７００の負荷を軽減する事ができる。

次に、ＡＰＩ上限検証処理の結果が［許可応答］である場合は、Ｓ３．１にて認可サーバーモジュール６００は認可トークンを発行する。より具体的には、認可トークンＩＤを発行し、認可コードに紐づくユーザーＩＤ、および認証したクライアントＩＤを認可トークン管理テーブル１４００に登録する。その際、トークン種別１４０２は認可トークンとし、有効期限１４０３に当該認可トークンが有効である日時を登録する。

そして、Ｓ３．２にて、認可サーバーモジュール６００は発行した認可トークンの認可トークンＩＤを連携サーバーモジュール８００に応答する。その際、認可トークンの有効期限を応答するよう構成する事もできる。本実施例では、ＯＡｕｔｈ２．０に規定された、認可トークンを更新するためのリフレッシュトークンを発行しない例で説明したが、認可トークン管理テーブル１４００にて、リフレッシュトークンのＩＤ、および有効期限を管理するよう構成する事もできる。その際、認可トークン発行時に同時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのＩＤも含めて応答するよう構成する事もできる。

認可トークンを取得した連携サーバーモジュール８００は、Ｓ３．３にてリソースサーバーモジュール７００が公開するＡＰＩに対してリソース要求を行う。リソース要求を受け付けたリソースサーバーモジュール７００は、Ｓ３．４にて認可トークン検証要求を認可サーバーモジュール６００に行う。この認可トークン検証要求には、検証対象となる認可トークンの認可トークンＩＤを含む。

Ｓ３．５にて、認可サーバーモジュール６００は、リソースサーバーモジュール７００より受けた認可トークンの検証を行う。認可サーバーモジュール６００は、取得した認可トークンＩＤを基に認可トークンの情報を取得する。より具体的には、認可トークン管理テーブル１４００から、認可トークンＩＤ、およびトークン種別が［認可トークン］に一致するデータ特定し、有効期限１４０３を取得する。そして、認可トークンが存在しているか、つまり、認可トークン管理テーブル１４００に存在するかの検証、および、有効期限内であるかを検証する。

認可サーバーモジュール６００は、認可トークン検証の結果、存在しない場合、もしくは存在するが有効期限内でない場合は認可トークンが［無効］と判断し、Ｓ３．８にてリソースサーバーモジュール７００に［拒否応答］を通知する。認可トークン検証要求の結果が［拒否応答］である場合は、リソースサーバーモジュール７００はＳ４．４にて、連携サーバーモジュール８００に対してエラーを応答する。Ｓ４．５にて連携サーバーモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。

認可サーバーモジュール６００は、認可トークンの検証の結果、認可トークンが存在し、かつ有効期限内である場合は認可トークンが［有効］と判断し、Ｓ３．６にてＡＰＩ上限検証処理を実行する。この際、認可トークンに紐づくユーザーＩＤ、およびクライアントＩＤを用いて処理を実行する。ＡＰＩ上限検証処理の詳細については後述する。

ＡＰＩ上限検証処理の結果が［拒否応答］である場合は、Ｓ３．８にてリソースサーバーモジュール７００に［拒否応答］を通知する。認可トークン検証要求の結果が［拒否応答］である場合は、リソースサーバーモジュール７００はＳ４．４にて、連携サーバーモジュール８００に対してエラーを応答する。Ｓ４．５にて連携サーバーモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。

ＡＰＩ上限検証処理の結果が［許可応答］である場合は、Ｓ３．７にて認可サーバーモジュール６００はＡＰＩの呼び出し回数の加算処理を実行する。より具体的には、後述するＡＰＩ上限検証処理が通常上限処理であった場合は、取得した認可トークンＩＤを基に認可トークン管理テーブル１４００からクライアントＩＤ１４０４を取得する。そして、取得したクライアントＩＤが、ＡＰＩ利用数上限管理テーブル１５００のクライアントＩＤ１５０１に一致するデータの期間あたりのコール数１５０６を１回分加算する。

また、後述するＡＰＩ上限検証処理が個別上限検証処理であった場合は、取得した認可トークンＩＤを基に、認可トークン管理テーブル１４００からクライアントＩＤ１４０４、およびユーザーＩＤ１４０５を取得する。さらに、取得したユーザーＩＤを基に、ユーザー管理テーブル１２００からテナントＩＤ１２０３を取得する。そして、取得したクライアントＩＤ、およびテナントＩＤが、テナント個別許可設定管理テーブル１８００のクライアントＩＤ１８０１、および許可テナントＩＤ１８０２の組に一致するデータの期間あたりのコール数１８０４を１回分加算する。そして、Ｓ３．８ にて認可サーバーモジュール６００はリソースサーバーモジュール７００に［許可応答］を通知する。認可トークン検証要求の結果が［許可応答］である場合は、リソースサーバーモジュール７００はＳ４．１にて、公開しているＡＰＩの機能に従ったリソース取得処理を実行し、取得したリソースをＳ４．２にて連携サーバーモジュール８００に応答する。Ｓ４．３にて連携サーバーモジュール８００は不図示の連携画面をＷｅｂブラウザー８２０に応答し、処理を終了する。以上が、連携サーバーモジュール８００が、リソースサーバーモジュール７００が公開するＡＰＩを利用するまでの説明である。

ここで、Ｓ１．１１、Ｓ２．１０にて、ＡＰＩ利用数の上限検証を実施する事による効果について詳細を説明する。例えば、ＡＰＩ利用数が上限に達しているかを検証するタイミングは、Ｓ１．１１、Ｓ２．１０、Ｓ３．３、Ｓ３．６の４か所で行う事が考えられる。まず、Ｓ３．３で行う場合、つまりリソースサーバーモジュール７００が独自でＡＰＩ利用数の上限を検証するケースでは、リソースサーバーモジュール７００で受けつけるＡＰＩの詳細な処理情報を用いて上限管理が可能となる。つまり、ＯＡｕｔｈ２．０の範疇で授受される粒度より詳細に上限管理を行う事ができるというメリットがある。一方、本発明の目的である、リソースサーバー３００の負荷軽減という観点では、リソースサーバーモジュール７００にて、独自にＡＰＩ利用数の上限を管理するモジュールの構成および、検証を実施する必要があり、逆に、かかる負荷が増加する事が予想される。さらに、リソースサーバー３００が複数存在し、それぞれ違うサービスを展開しＡＰＩを公開している構成では、それぞれのリソースサーバー３００にてＡＰＩ利用数の上限を管理するモジュールを構成する必要があり非効率である。さらには、クライアントからの観点では、利用するリソースサーバー３００のＡＰＩ毎にＡＰＩ利用数の上限管理方法が違う事が発生しうるため、クライアント側の処理制御が複雑になってしまう可能性がある。

次に、Ｓ３．６のみで行う場合、つまり、リソースサーバーモジュール７００が、認可サーバーモジュール６００に対して、ＡＰＩ利用数が上限に達しているかを検証するケースである。本ケースでは、例えば、リソースサーバー３００が複数存在し、それぞれ違うサービスを展開しＡＰＩを公開していたとしても、統一的なＡＰＩ利用数の上限管理方法を実現する事が可能となる。結果、クライアントからの観点にて、クライアント側の処理制御が容易になる。一方、本発明の目的である、リソースサーバー３００の負荷軽減という観点では、上述の通り、ＡＰＩ利用数が上限に達していた場合においても、リソースサーバーモジュール７００は、Ｓ３．３からＳ３．８の処理を実行しなければならず、完全に負荷が軽減されているとはいいがたい。特に、Ｓ３．３にてクライアントからリソース要求を受け付けるという事は、リソースサーバーモジュール７００にてＷＡＮ１００および、ＬＡＮ１０１を介した通信を確立する必要があり、ネットワークリソースにかかる負荷が軽減できない。

Ｓ１．１１、およびＳ２．１０の認可トークンの発行を制限するケースについて説明する。本ケースでは、本発明の目的であるリソースサーバー３００にかかる負荷軽減の効果はもっとも高いと考えられる。しかしながら、ＯＡｕｔｈ２．０における認可トークンは、有効期限内であれば、何度も再利用可能な構成が一般的である。これは、複数ＡＰＩを連続実行する事で、一つのサービスが成立するようなケースでは有用であるが、ＡＰＩ利用数の上限を管理するという面では、厳密に利用数をカウントできない、というデメリットが生じる。結果、ＡＰＩの利用数の上限に達しているにもかかわらず、有効期限内の認可トークンを再利用されることによって、結果的に、リソースサーバー３００にかかる負荷を制御できない、というデメリットが生じてしまう。

結果、本発明では、Ｓ３．６の検証処理のタイミングでＡＰＩ利用数の上限管理する方法に合わせて、Ｓ１．１１、およびＳ２．１０の認可トークンの発行処理のタイミングで認可トークンの発行を制限することを同時実現することで、リソースサーバー３００にかかる負荷を制御するという目的に対しより格別な効果が発揮できる構成としている。

次に、認可サーバーモジュール６００にて処理される上限検証処理について図９、図１０、図１１を用いて説明する。図９は認可サーバーモジュール６００にて行われるＡＰＩ上限検証処理のフローチャートである。本フローは図７を用いて説明した処理の内、Ｓ１．１１、Ｓ２．１０、Ｓ３．６にて呼び出され処理される。Ｓ５．１にてＡＰＩ上限検証処理の依頼を受けた認可サーバーモジュール６００は、Ｓ５．２ にて依頼に合わせて通知されたクライアントＩＤ、ユーザーＩＤを取得する。次に、Ｓ５．３にてＡＰＩ利用数上限管理テーブル１５００から、取得したクライアントＩＤの上限時モード１５０５を取得する。

Ｓ５．４にて認可サーバーモジュール６００は、取得した上限時モード１５０５が［超過分後払い］だった場合は、Ｓ５．５にて［許可応答］を応答し処理を終了する。その際、上限検証処理の種別は通常上限検証処理として応答する。Ｓ５．４にて認可サーバーモジュール６００は、取得した上限時モード１５０５が［拒否］だった場合は、Ｓ５．６にてテナント個別設定管理テーブル１６００から、取得したクライアントＩＤのテナント個別拒否設定１６０２、テナント個別許可設定１６０３を取得する。

Ｓ５．７にて認可サーバーモジュール６００は、取得したテナント個別拒否設定１６０２、テナント個別許可設定１６０３が共に［設定しない］だった場合は、Ｓ５．８にて通常上限検証処理を実行する。通常上限検証処理の詳細については後述する。Ｓ５．７にて認可サーバーモジュール６００は、取得したテナント個別拒否設定１６０２、テナント個別許可設定１６０３が、少なくともどちらかが［設定する］だった場合は、Ｓ５．９にて取得したユーザーＩＤからテナントＩＤを取得する。より詳細には、ユーザー管理テーブル１２００から、ユーザーＩＤをキーとしてテナントＩＤ１２０３を取得する。ここで取得したテナントＩＤとは、ＯＡｕｔｈ２．０としては、クライアントに対して権限委譲した、つまり権限委譲元のユーザーが所属するテナントを識別するための情報となる。

次に、Ｓ５．８にて認可サーバーモジュール６００は、取得したテナント個別拒否設定１６０２が［設定しない］であればＳ５．１３に処理を移動する。取得したテナント個別拒否設定１６０２が［設定する］であればＳ５．１１にて取得したテナントＩＤのテナントが拒否対象であるか否かを確認する。より具体的には、取得したクライアントＩＤ、テナントＩＤの組がテナント個別拒否設定管理テーブル１７００に登録されているかを確認する。登録されている場合は、拒否テナントとして、Ｓ５．１２にて［拒否応答］を応答し処理を終了する。登録されていない場合は、Ｓ５．１３に処理を移動する。

Ｓ５．１３にて、認可サーバーモジュール６００は取得したテナント個別許可設定１６０３が［設定しない］であればＳ５．８にて通常上限検証処理を実行する。通常上限検証処理の詳細については後述する。取得したテナント個別許可設定１６０３が［設定する］であれば、Ｓ５．１４にて取得したテナントＩＤのテナントが個別設定の対象であるかを確認する。より具体的には、取得したクライアントＩＤ、テナントＩＤの組がテナント個別許可設定テーブル１８００に登録されているか、を確認する。登録されていない場合はＳ５．８にて通常上限検証処理を実行する。通常上限検証処理の詳細については後述する。登録されている場合はＳ５．１５にて個別上限検証処理を実行する。個別上限検証処理の詳細については後述する。

図１０は認可サーバーモジュール６００にて行われる通常上限検証処理のフローチャートである。本フローは図９を用いて説明した処理の内、Ｓ５．８にて呼び出され処理される。

Ｓ６．１にて認可サーバーモジュール６００は、取得したクライアントＩＤにてＡＰＩ利用数上限管理テーブル１５００から上限値１５０２、期間あたりのコール数１５０６を取得する。そして、Ｓ６．２にて、期間あたりのコール数１５０６の回数が、上限値１５０２の回数以下であるかを確認する。上限値１５０２の回数を上回る場合は、Ｓ６．３にて［拒否応答］を応答し処理を終了する。上限値１５０２の回数以下である場合は、Ｓ６．４にて［許可応答］を応答し処理を終了する。その際、上限検証処理の種別は通常上限検証処理として応答する。

図１１は認可サーバーモジュール６００にて行われる個別上限検証処理のフローチャートである。本フローは図９を用いて説明した処理の内、Ｓ５．１５にて呼び出される処理である。

Ｓ７．１にて認可サーバーモジュール６００は、取得したクライアントＩＤ、テナントＩＤにてテナント個別許可設定管理テーブル１８００から上限値１８０３、期間あたりのコール数１８０４を取得する。そして、Ｓ７．２にて、期間あたりのコール数１８０４の回数が、上限値１８０３の回数以下であるかを確認する。上限値１８０３の回数を上回る場合は、Ｓ７．３にて［拒否応答］を応答し処理を終了する。上限値１８０３の回数以下である場合は、Ｓ７．４にて［許可応答］を応答し処理を終了する。その際、上限検証処理の種別は個別上限検証処理として応答する。

以上が、認可サーバーモジュール６００にて処理される上限検証処理の説明である。これら処理、特にテナント個別許可設定および、個別上限検証処理によってＯＡｕｔｈ２．０の権限委譲元のユーザーが所属するテナントごとにＡＰＩ利用数の上限を管理する事が可能となる。つまり、クライアントからＡＰＩ利用された場合に、ＡＰＩ利用数について権限委譲元のテナント間の偏りを解消する事ができる。

図９で説明した上限検証処理フローでは、Ｓ５．１４にてテナント個別許可設定されていないテナントであった場合は、通常上限検証処理を実行するとして説明した。しかし、その処理フローでは、テナント個別許可設定していないテナントが複数存在した場合、その複数の許可外設定外のテナント間でＡＰＩ利用数の偏りが発生する課題が残る。

一方、連携サーバー４００を用いてクラウドサービスを展開している事業者と、認可サーバー２００、リソースサーバー３００を用いてクラウドサービスを展開している事業者は、違う事業者である事が想定される。その場合、セキュリティや契約の関係上、連携サーバー４００の管理者が、認可サーバー２００にて管理しているユーザー管理テーブル１２００に登録されている全てのテナントの情報を把握する事は困難である。また、ユーザー管理テーブル１２００に登録されている全てのユーザーが連携サーバー４００の利用者であるとは限らない。そのため、連携サーバー４００の管理者が連携サーバー４００からリソースサーバー３００のＡＰＩを利用する全てのユーザーの所属テナントを事前にテナント個別許可設定する事は難しい。

結果として、テナント個別許可設定していないテナント間でＡＰＩ利用数の偏りが発生する課題が発生する可能性がある。

そこで、上記課題を解決するための第２の実施形態について図１２、図１３および図１４を用いて説明する。なお、第２の実施形態では、図６ｃ、図９以外には差異が無いため説明を省略する。また、図６ｃ、図９と同様の構成および、同じ処理を実施する箇所については同じ番号を付与し説明を省略する。

図１２は、第２の実施形態の認可サーバー２００がＬＡＮ１０１を介して通信可能に構成されたデータベースサーバー５００の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリに構成する事もできる。

図１２はテナント個別詳細設定管理テーブル１９００である。テナント個別詳細設定管理テーブル１９００は、クライアントＩＤ１９０１、未登録テナントモード１９０２、自動設定値１９０３、設定上限値１９０５、および設定上限時モード１９０６から成る。これらテナント個別詳細設定管理テーブル１９００の処理の詳細については後述する。

図１３はテナント個別許可設定画面４０００である。この画面は、連携サーバー４００の管理者か、もしくは管理を委譲されているユーザーが利用するＷｅｂブラウザー８２０に表示される画面である。なお、本画面は図６ａを用いて説明したＡＰＩ利用数上限管理画面２０００にて、テナント個別許可設定ボタン２００４を押下した場合に生成される画面である。テナント個別許可設定画面４０００は、図６ｃを用いて説明したテナント個別許可設定画面２２００に第２の実施形態の特徴を追加した画面となっている。なお、テナント個別許可設定画面２２００と同様の構成については同じ番号を付与しており説明を省略する。

テナント個別許可設定画面４０００は、テナント個別許可設定画面２２００の構成に対して、詳細設定４００１、設定ボタン４００２を追加で構成している。設定ボタン４００２は、詳細設定４００１の各項目の選択状態を設定、反映するためのボタンである。設定ボタン４００２が押下された場合、未登録テナントからの利用された場合の動作、未登録テナントを自動的に登録するか、および、自動登録時の各設定値が、Ｗｅｂブラウザー８２０から認可サーバーモジュール６００に通知される。通知を受けた認可サーバーモジュール６００は、特定したクライアントＩＤを用いてテナント個別詳細設定管理テーブル１９００の各項目に反映する。より具体的には、テナント個別詳細設定管理テーブル１９００において、特定したクライアントＩＤを元に、クライアントＩＤ１９０１、未登録テナントモード１９０２、自動設定値１９０３、設定上限値１９０５、および設定上限時モード１９０６に値を反映する。

図１４は認可サーバーモジュール６００にて行われるＡＰＩ上限検証処理のフローチャートである。本フローは図７を用いて説明した処理の内、Ｓ１．１１、Ｓ２．１０、Ｓ３．６にて呼び出され処理される。本フローは、図９を用いて説明したＡＰＩ上限検証処理フローに第２の実施形態の特徴を追加したフローとなっている。なお、図９のＡＰＩ上限検証処理フローと同様のフローについては同じ番号を付与しており説明を省略する。

認可サーバーモジュール６００は、Ｓ５．１４にて取得したテナントＩＤのテナントが個別設定の対象であるかを確認する。より具体的には、取得したクライアントＩＤ、テナントＩＤの組がテナント個別許可設定テーブル１８００に登録されているかを確認する。登録されている場合はＳ５．１５にて個別上限検証処理を実行する。登録されていない場合は、取得したクライアントＩＤを基に、Ｓ８．１にてテナント個別詳細設定テーブル１９００の未登録テナントモード１９０２を確認する。未登録テナントモードが［拒否］の場合はＳ８．２にて［拒否応答］を応答し処理を終了する。未登録テナントモードが［許可］の場合は、Ｓ８．３にて取得したクライアントＩＤを基に、テナント個別詳細設定テーブル１９００の自動登録１９０３を確認する。自動登録１９０３が［しない］の場合はＳ５．８にて通常上限検証処理を実行する。自動登録１９０３が［する］の場合はＳ８．４にて、取得したクライアントＩＤを元にテナント個別設定管理テーブル１６００のテナント個別上限値合計１６０４、テナント個別詳細設定管理テーブル１９００の自動設定値１９０４、および設定上限値１９０５を取得する。

認可サーバーモジュール６００はＳ８．５にて、自動設定値１９０４とテナント個別上限値合計１６０４を加算した値が、設定上限値１９０５以下であるかを確認する。設定上限値１９０５の値以下である場合は、Ｓ８．６にてテナントを自動登録する。より具体的には、テナント個別許可設定管理テーブル１８００に対して、取得したクライアントＩＤ、テナントＩＤ、および自動設定値１９０４を上限値として設定する。そして、Ｓ５．１５にて個別上限検証処理を実行する。設定上限値１９０５を上回る場合は、Ｓ８．７にて、取得したクライアントＩＤを元に、テナント個別詳細設定テーブル１９００の設定上限時モード１９０６を取得し、確認する。

認可サーバーモジュール６００は、設定上限時モード１９０６が［拒否する］の場合は、Ｓ８．８にて［拒否応答］を応答し、処理を終了する。設定上限時モード１９０６が［許可する］の場合は、Ｓ５．８にて通常上限検証処理を実行する。

上記処理により、連携サーバー４００の管理者が、テナント個別許可設定をしていないテナントからのＡＰＩ利用が来た場合の制御を設定可能となり、設定によっては、テナント個別許可設定していない複数のテナント間のＡＰＩ利用数の偏りを回避する事ができる。

（その他の実施例）
本願発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

また、本願発明はクライアントとしてインターネット上のサービスを例に説明をした。しかしながら、端末に備えられたアプリケーションがクライアントであっても良い。

２００ 認可サーバー
３００ リソースサーバー
４００ 連携サーバー
５００ データベースサーバー
６００ 認可サーバーモジュール
７００ リソースサーバーモジュール
８００ 連携サーバーモジュール
８２０ Ｗｅｂブラウザー

Claims (11)

1. ネットワークを介して提供されるサービスの利用を制限する認可サーバーシステムであって、
   ユーザーの前記サービスを利用する権限をクライアントへ委譲することを許可する認可操作が行われたことに応じて認可情報を発行する認可処理手段と、
   前記認可処理手段により発行された認可情報を取得した前記クライアントが前記サービスを利用する際に送信する前記認可情報を検証し、当該検証の結果、前記クライアントに対し前記ユーザーの権限で前記サービスの利用を許可する検証処理手段と、
   前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断する判断手段と、
   前記判断手段により超えていると判断された場合、前記関数の利用を制限する制限手段と、を有し、
   前記判断手段は、前記認可処理手段により前記認可情報が発行される際と、前記検証処理手段により前記認可情報が検証される際の両方のタイミングにおいて、前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断することを特徴とする認可サーバーシステム。
2. 前記ユーザーが属するグループを特定するグループＩＤと、前記関数の利用数の上限とを関連付けた情報を前記グループＩＤ毎に登録するテーブルを保持する保持手段を更に有し、
   前記判断手段は、前記クライアントが前記ユーザーの権限で前記サービスを利用する場合、前記ユーザーに対応する前記グループＩＤを特定し、特定された前記グループＩＤに対応する前記関数の利用数の上限に基づき前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断することを特徴とする請求項１に記載の認可サーバーシステム。
3. 前記関数の利用の拒絶、および／または許可を前記グループＩＤ毎に設定するための管理画面を提供する提供手段を更に有し、
   前記画面を介し拒絶が指定されたグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合、エラー応答を行うことを特徴とする請求項２に記載の認可サーバーシステム。
4. 前記提供手段は、前記管理画面を介し許可が指定されたグループＩＤに対し、当該グループＩＤに対して前記関数の利用数の上限を設定するための前記管理画面を提供し、
   前記保持手段が保持するテーブルには、前記管理画面を介し許可が指定されたグループＩＤと、前記管理画面において設定された前記関数の利用数の上限とが関連付けた情報が登録されていることを特徴とする請求項３に記載の認可サーバーシステム。
5. 前記提供手段は、前記管理画面を介し拒絶、および許可の何れも指定されていない未登録のグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合に前記関数の利用を拒絶、または許可を設定するための前記管理画面を提供し、
   更に、前記提供手段は、未登録のグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合に、未登録テナントのグループＩＤを自動的に前記テーブルに登録するか否かの設定、および自動的に前記テーブルに登録する際に設定される前記関数の利用数の上限の設定をするための前記管理画面を提供することを特徴とする請求項３または４に記載の認可サーバーシステム。
6. ネットワークを介して提供されるサービスの利用を制限する認可サーバーシステムを制御する制御方法であって、
   認可処理手段は、ユーザーの前記サービスを利用する権限をクライアントへ委譲することを許可する認可操作が行われたことに応じて認可情報を発行し、
   検証処理手段は、前記認可処理手段により発行された認可情報を取得した前記クライアントが前記サービスを利用する際に送信する前記認可情報を検証し、当該検証の結果、前記クライアントに対し前記ユーザーの権限で前記サービスの利用を許可し、
   判断手段は、前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断し、
   制限手段は、前記判断手段により超えていると判断された場合、前記関数の利用を制限し、
   更に、前記判断手段は、前記認可処理手段により前記認可情報が発行される際と、前記検証処理手段により前記認可情報が検証される際の両方のタイミングにおいて、前記サービスを利用するために前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断することを特徴とする制御方法。
7. 保持手段は、前記ユーザーが属するグループを特定するグループＩＤと、前記関数の利用数の上限とを関連付けた情報を前記グループＩＤ毎に登録するテーブルを保持し、
   前記判断手段は、前記クライアントが前記ユーザーの前記サービスを利用する場合、前記ユーザーに対応する前記グループＩＤを特定し、特定された前記グループＩＤに対応する前記関数の利用数の上限に基づき前記クライアントが呼び出す関数の利用数が上限を超えているか否かを判断することを特徴とする請求項６に記載の制御方法。
8. 提供手段は、前記関数の利用の拒絶、および／または許可を前記グループＩＤ毎に設定するための管理画面を提供し、
   前記画面を介し拒絶が指定されたグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合、エラー応答を行うことを特徴とする請求項７に記載の制御方法。
9. 前記提供手段は、前記管理画面を介し許可が指定されたグループＩＤに対し、当該グループＩＤに対して前記関数の利用数の上限を設定するための前記管理画面を提供し、
   前記保持手段が保持するテーブルには、前記管理画面を介し許可が指定されたグループＩＤと、前記管理画面において設定された前記関数の利用数の上限とが関連付けた情報が登録されていることを特徴とする請求項８に記載の制御方法。
10. 前記提供手段は、前記管理画面を介し拒絶、および許可の何れも指定されていない未登録のグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合に前記関数の利用を拒絶、または許可を設定するための前記管理画面を提供し、
    更に、前記提供手段は、未登録のグループＩＤに対応するユーザーの権限で前記クライアントがアクセスしてきた場合に、未登録テナントのグループＩＤを自動的に前記テーブルに登録するか否かの設定、および自動的に前記テーブルに登録する際に設定される前記関数の利用数の上限の設定をするための前記管理画面を提供することを特徴とする請求項８または９に記載の制御方法。
11. 請求項６乃至１０の何れか１項に記載の制御方法をコンピュータに実行させるためのプログラム。

Images