"URLに対応する画面を提供するか否かをロール情報によって管理し、APIの実行権限をロール情報によって管理し、データを配信するか否かをロール情報によって管理する管理手段と、リソースに対するアクセス可否確認と認証トークンとを受信する受信手段と、前記受信手段により受信された前記認証トークンに関連付けられたロール情報を決定する決定手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がURLリソースの場合に、前記決定手段により決定された前記ロール情報と前記URLリソースのロール情報とに基づいてアクセスを許可するか否か前記管理手段の管理内容に基づいて検証するURL検証手段と、前記URL検証手段によりアクセスを許可すると判定された場合、前記URLリソースに対応する画面を提供する提供手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がAPIの実行である場合に、前記決定手段により決定された前記ロール情報と前記APIの実行権限のロール情報とに基づいてアクセスを許可するか否かを前記管理手段の管理内容に基づいて検証するAPI検証手段と、前記API検証手段によりアクセスを許可すると判定された場合、前記APIを実行する実行手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がデータの配信である場合に、前記決定手段により決定された前記ロール情報と前記データの配信のロール情報とに基づいてアクセスを許可するか否かを前記管理手段の管理内容に基づいて検証するデータ配信検証手段と、前記データ配信検証手段によりアクセスを許可すると判定された場合、前記データを配信する配信手段を備えることを特徴とする認証システム。ユーザーのユーザー識別情報を用いて前記ユーザーが所属するテナントと前記ユーザーのロール情報を特定できるユーザー情報を記憶する第1記憶手段と、前記受信手段により前記ユーザーから認証要求としてユーザー識別情報が受信された場合、受信されたユーザー識別情報と前記第1記憶手段に記憶された前記ユーザー情報とに基づいて前記ユーザーが正当なユーザーであるか否かを判定する判定手段と、前記判定手段により前記ユーザーが正当なユーザーであると判定された場合、前記ユーザーの認証トークンを生成する生成手段と、前記生成手段により生成された前記ユーザーの認証トークンと、前記ユーザー情報に基づいて特定される前記ユーザーのロール情報とが関連づけられた認証トークン情報を記憶する第2記憶手段を更に備え、前記決定手段は、前記認証トークン情報を用いて前記認証トークンに関連付けられたロール情報を決定することを特徴とする請求項1に記載の認証システム。データリソースからロール情報を特定できるリソース情報を記憶する第2記憶手段を更に有し、前記URL検証手段、API検証手段およびデータ配信検証手段は、前記認証トークン情報と前記リソース情報を用いて検証することを特徴とする請求項2に記載の認証システム。要求される複数の種別のリソース種別のそれぞれについて、ロールが管理されたロール管理情報を管理する管理手段と、リソースに対するアクセス可否確認と認証トークンとを受信する受信手段と、前記受信手段により受信された前記認証トークンに関連付けられたロール情報を決定する第1決定手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別のロール情報を前記管理手段により管理されている前記ロール管理情報を取得する取得手段と、前記取得手段により取得された前記リソース種別に対応するロール情報と前記第1決定手段により決定されたロール情報により前記リソース種別へのアクセスを許可するか否かを決定する第2決定手段を備えることを特徴とする認証システム。URLに対応する画面を提供するか否かをロール情報によって管理し、APIの実行権限をロール情報によって管理し、データを配信するか否かをロール情報によって管理する管理工程と、リソースに対するアクセス可否確認と認証トークンとを受信する受信工程と、前記受信工程により受信された前記認証トークンに関連付けられたロール情報を決定する決定工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がURLリソースの場合に、前記決定工程により決定された前記ロール情報と前記URLリソースのロール情報とに基づいてアクセスを許可するか否か前記管理工程の管理内容に基づいて検証するURL検証工程と、前記URL検証工程によりアクセスを許可すると判定された場合、前記URLリソースに対応する画面を提供する提供工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がAPIの実行である場合に、前記決定工程により決定された前記ロール情報と前記APIの実行権限のロール情報とに基づいてアクセスを許可するか否かを前記管理工程の管理内容に基づいて検証するAPI検証工程と、前記API検証工程によりアクセスを許可すると判定された場合、前記APIを実行する実行工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がデータの配信である場合に、前記決定工程により決定された前記ロール情報と前記データの配信のロール情報とに基づいてアクセスを許可するか否かを前記管理工程の管理内容に基づいて検証するデータ配信検証工程と、前記データ配信検証工程によりアクセスを許可すると判定された場合、前記データを配信する配信工程を備えることを特徴とする認証方法。ユーザーのユーザー識別情報を用いて前記ユーザーが所属するテナントと前記ユーザーのロール情報を特定できるユーザー情報を記憶する第1記憶工程と、前記受信工程により前記ユーザーから認証要求としてユーザー識別情報が受信された場合、受信されたユーザー識別情報と前記第1記憶工程に記憶された前記ユーザー情報とに基づいて前記ユーザーが正当なユーザーであるか否かを判定する判定工程と、前記判定工程により前記ユーザーが正当なユーザーであると判定された場合、前記ユーザーの認証トークンを生成する生成工程と、前記生成工程により生成された前記ユーザーの認証トークンと、前記ユーザー情報に基づいて特定される前記ユーザーのロール情報とが関連づけられた認証トークン情報を記憶する第2記憶工程を更に備え、前記決定工程は、前記認証トークン情報を用いて前記認証トークンに関連付けられたロール情報を決定することを特徴とする請求項5に記載の認証方法。データリソースからロール情報を特定できるリソース情報を記憶する第2記憶工程を更に有し、前記URL検証工程、API検証工程およびデータ配信検証工程は、前記認証トークン情報と前記リソース情報を用いて検証することを特徴とする請求項6に記載の認証方法。要求される複数の種別のリソース種別のそれぞれについて、ロールが管理されたロール管理情報を管理する管理工程と、リソースに対するアクセス可否確認と認証トークンとを受信する受信工程と、前記受信工程により受信された前記認証トークンに関連付けられたロール情報を決定する第1決定工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別のロール情報を前記管理工程により管理されている前記ロール管理情報を取得する取得工程と、前記取得工程により取得された前記リソース種別に対応するロール情報と前記第1決定工程により決定されたロール情報により前記リソース種別へのアクセスを許可するか否かを決定する第2決定工程を備えることを特徴とする認証方法。URLに対応する画面を提供するか否かをロール情報によって管理し、APIの実行権限をロール情報によって管理し、データを配信するか否かをロール情報によって管理する管理工程と、リソースに対するアクセス可否確認と認証トークンとを受信する受信工程と、前記受信工程により受信された前記認証トークンに関連付けられたロール情報を決定する決定工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がURLリソースの場合に、前記決定工程により決定された前記ロール情報と前記URLリソースのロール情報とに基づいてアクセスを許可するか否か前記管理工程の管理内容に基づいて検証するURL検証工程と、前記URL検証工程によりアクセスを許可すると判定された場合、前記URLリソースに対応する画面を提供する提供工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がAPIの実行である場合に、前記決定工程により決定された前記ロール情報と前記APIの実行権限のロール情報とに基づいてアクセスを許可するか否かを前記管理工程の管理内容に基づいて検証するAPI検証工程と、前記API検証工程によりアクセスを許可すると判定された場合、前記APIを実行する実行工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別がデータの配信である場合に、前記決定工程により決定された前記ロール情報と前記データの配信のロール情報とに基づいてアクセスを許可するか否かを前記管理工程の管理内容に基づいて検証するデータ配信検証工程と、前記データ配信検証工程によりアクセスを許可すると判定された場合、前記データを配信する配信工程をコンピュータに実行させるためのプログラム。ユーザーのユーザー識別情報を用いて前記ユーザーが所属するテナントと前記ユーザーのロール情報を特定できるユーザー情報を記憶する第1記憶工程と、前記受信工程により前記ユーザーから認証要求としてユーザー識別情報が受信された場合、受信されたユーザー識別情報と前記第1記憶工程に記憶された前記ユーザー情報とに基づいて前記ユーザーが正当なユーザーであるか否かを判定する判定工程と、前記判定工程により前記ユーザーが正当なユーザーであると判定された場合、前記ユーザーの認証トークンを生成する生成工程と、前記生成工程により生成された前記ユーザーの認証トークンと、前記ユーザー情報に基づいて特定される前記ユーザーのロール情報とが関連づけられた認証トークン情報を記憶する第2記憶工程を更に備え、前記決定工程は、前記認証トークン情報を用いて前記認証トークンに関連付けられたロール情報を決定することを特徴とする請求項9に記載のプログラム。データリソースからロール情報を特定できるリソース情報を記憶する第2記憶工程を更に有し、前記URL検証工程、API検証工程およびデータ配信検証工程は、前記認証トークン情報と前記リソース情報を用いて検証することを特徴とする請求項10に記載のプログラム。要求される複数の種別のリソース種別のそれぞれについて、ロールが管理されたロール管理情報を管理する管理工程と、リソースに対するアクセス可否確認と認証トークンとを受信する受信工程と、前記受信工程により受信された前記認証トークンに関連付けられたロール情報を決定する第1決定工程と、前記受信工程により受信されたアクセス可否確認に対応するリソース種別のロール情報を前記管理工程により管理されている前記ロール管理情報を取得する取得工程と、前記取得工程により取得された前記リソース種別に対応するロール情報と前記第1決定工程により決定されたロール情報により前記リソース種別へのアクセスを許可するか否かを決定する第2決定工程を備えることを特徴とするプログラム。マルチテナントサービスの場合、従来のテナントごとに専用のサーバーを用いる形態と比較してコスト削減を図る事が可能となる。しかしながら、例えば、先行技術で提案されているマルチテナントサービスにおけるアクセス制御方法は、その目的に特化して設計、開発されている。そのため、マルチテナントサービスの課題を解決するためのデータアクセス制御方法に対して、専用の設計、開発、および運用、保守のコストがかかってしまうという課題があった。一方、従来のWebアプリケーションのアクセス制御方法としてロールを用いた方法が知られている。たとえば、WWWWorldWideWebに展開する有償のWebアプリケーションは、ユーザー認証の機構を備え、有償利用の契約をしたユーザーのみアクセスできるよう制御する方法を備えるのが通常である。その方法として、WWW上のURLUniformResourceLocatorへのアクセス権に対応してロールを定義し、ユーザーがロールを保持しているかでアクセス制御する方法が知られている。また、従来のアクセス制御方法として、ユーザーの権限によって実行可能な機能を制御する方法が知られている。たとえば、ユーザー情報の取得、作成、削除は管理者権限が必要であり、管理者である事を示すロールをユーザーが保持しているかによって、機能の実行を許可するか、拒否するかを制御する方法である。本発明は、マルチテナントサービスにおいて、従来のアクセス制御方法と統一的な方法を用いて課題を解決する事により、出来る限り専用のコストをかけずに実現する事を目的としている。上記課題を解決するために本願の認証システムは、URLに対応する画面を提供するか否かをロール情報によって管理し、APIの実行権限をロール情報によって管理し、データを配信するか否かをロール情報によって管理する管理手段と、リソースに対するアクセス可否確認と認証トークンとを受信する受信手段と、前記受信手段により受信された前記認証トークンに関連付けられたロール情報を決定する決定手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がURLリソースの場合に、前記決定手段により決定された前記ロール情報と前記URLリソースのロール情報とに基づいてアクセスを許可するか否か前記管理手段の管理内容に基づいて検証するURL検証手段と、前記URL検証手段によりアクセスを許可すると判定された場合、前記URLリソースに対応する画面を提供する提供手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がAPIの実行である場合に、前記決定手段により決定された前記ロール情報と前記APIの実行権限のロール情報とに基づいてアクセスを許可するか否かを前記管理手段の管理内容に基づいて検証するAPI検証手段と、前記API検証手段によりアクセスを許可すると判定された場合、前記APIを実行する実行手段と、前記受信手段により受信されたアクセス可否確認に対応するリソース種別がデータの配信である場合に、前記決定手段により決定された前記ロール情報と前記データの配信のロール情報とに基づいてアクセスを許可するか否かを前記管理手段の管理内容に基づいて検証するデータ配信検証手段と、前記データ配信検証手段によりアクセスを許可すると判定された場合、前記データを配信する配信手段を備えることを特徴とする。本発明により、コストをかけることなくサービスを実現する事ができる。以下、本発明を実施するための最良の形態について図面を用いて説明する。図1は、本発明の実施例のシステム構成を示すブロック図である。図中10は、WideAreaNetworkWAN10であり、本発明ではWorldWideWebWWWシステムが構築されている。図中11は各構成要素を接続するLocalAreaNetworkLAN11である。図中12はWAN10を介して各サービスに対してWebリクエストを発行する複数のクライアント12A、12Bであり、より具体的にはWWWシステムを利用するためのWebブラウザを備えたコンピュータである。なお、クライアント12Aおよび、クライアント12Bは、不図示のファイアウォール装置により、WAN10に対するリクエスト以外の通信が遮断されている。図中13はWAN10およびLAN11を介して、クライアント12からのWebリクエスト要求に応じて、ユーザーを認証するためのログイン画面を提示し、ユーザーからのログインリクエストを受け付けるログインサービス13である。図中14はLAN11を介して、ログインサービス13および、一つないし複数のサービス15からのアクセス許可リクエストを受け付けるアクセス制御サービス14である。図中15はWAN10およびLAN11を介して、クライアント12からのWebリクエスト要求に応じて、各種サービスを提供する一つないし複数のサービス15A、サービス15Bである。図中16はLAN11を介してアクセス制御サービス14からのデータアクセス要求をうけつけるデータベースサービス16である。データベースサービス16は、一般的なDBMSDataBaseManagementSystemが構成されており、アクセス制御サービス14からのデータアクセスクエリをうけつけ、該当するデータを応答する。図2は、図1中のクライアント12、ログインサービス13、アクセス制御サービス14、サービス15、あるいはデータベースサービス16のハードウェア構成を示すブロック図である。図中、21は内部バスで接続される各デバイス後述のROM、RAM他を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するCPUである。22はBIOSが格納してあるROMである。23はCPU21のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするRAM直接記憶装置。24は基本ソフトウェアであるOSやソフトウェアモジュールが記憶されているHDDハードディスクドライブ、もしくはSSDソリッドステートドライブなどの間接記憶装置。25は入力装置であり不図示のキーボードやポインティングデバイスなどである。26は出力装置でありディスプレイが接続される。27はWAN10ないしはLAN11に接続するためのI/FInterfaceであり、一つないしは複数備えている。これらハードウェアでは、起動後CPU21によりBIOSが実行されOSがHDD24からRAM23に実行可能にロードされる。CPU21はOSの動作に従って後述する各種ソフトウェアモジュールをHDD24からRAM23に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの協調によりCPU21によって実行され動作する。また、I/F27はLAN11に接続されており、OSの動作に従ってCPU21により制御され、各サーバーに格納されたサービス間のリクエストの送受信を実現している。また、I/F27はLAN11を経由してWAN10に接続されており、OSの動作に従ってCPU21により制御され、WWWシステムにおける通信を実現している。また、図中1のログインサービス13、アクセス制御サービス14、サービス15、あるいはデータベースサービス16は、一台、ないしは複数台の図2で示されたハードウェア構成のサーバーによって構成される。複数台のサーバーで構成する場合は、不図示のロードバランサー装置や、不図示のソフトウェアモジュールによって負荷分散構成、もしくは冗長化構成を採用する事ができる。図3は、ログインサービス13上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図2で示したHDD24に記憶されており、前述したようにCPU21によってRAM23にロードされ実行される。Webサーバー31は、クライアント12からのWebリクエストを受け付けるWebインタフェースを備えたWebアプリケーションサーバーである。ログインアプリケーション32は、Webサーバー31上にアプリケーションとして構成され、Webサーバー31が受け付けたWebリクエストに対して、ログイン画面を生成する。アクセス制御エージェント33は、Webサーバー31上にフィルタリングアプリケーションとして構成され、ログインアプリケーション32に対するWebリクエストをフィルタリングする。そして、アクセス制御サービス14に構成されるアクセス制御エージェントI/F41と通信することによりユーザーの認証処理を実行する。以後、上記ソフトウェアモジュールの協調により実行される一連の認証処理をログインサービス13で実行される処理と記載する。なお、ログインサービス13で実行されるユーザーの認証処理の詳細については後述する。図4は、アクセス制御サービス14上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図2で示したHDD24に記憶されており、前述したようにCPU21によってRAM23にロードされ実行される。図中41はログインサービス13、サービス15に構成されるアクセス制御エージェント33および53からのリクエスト受付およびレスポンス応答を行うアクセス制御エージェントI/F41である。図中42はサービス15に構成されるアクセス制御サービスI/F54からのAPI呼出の受付およびAPI実行結果の応答を行うアクセス制御サービスAPI42である。なお、APIとは、ApplicationProgramInterfaceの略である。アクセス制御部43は、アクセス制御エージェントI/F41、アクセス制御サービスAPI42からアクセス権確認を受け付け、制御するアプリケーションモジュールである。アクセス部43は、DBドライバ部44を介してデータベースサービス16のデータ取得や更新を行う。以後、上記ソフトウェアモジュールの協調により実行される一連のアクセス制御処理をアクセス制御サービス14で実行される処理と記載する。なお、アクセス制御サービス14で実行されるアクセス制御処理の詳細は後述する。図5は、サービス15A、15B上で動作するソフトウェアモジュールの構成例である。なお各ソフトウェアモジュールは図2で示したHDD24に記憶されており、前述したようにCPU21によってRAM23にロードされ実行される。Webサーバー51は、クライアント12からのWebリクエストを受け付けるWebインタフェースを備えたWebアプリケーションサーバーである。Webアプリケーション52は、Webサーバー51上にアプリケーションとして構成され、Webサーバー51が受け付けたWebリクエストに対して、サービスを提供する画面を生成する。アクセス制御エージェント53は、Webサーバー51上にフィルタリングアプリケーションとして構成され、Webアプリケーション52に対するWebリクエストをフィルタリングする。そして、アクセス制御サービス14に構成されるアクセス制御エージェントI/F41と通信することによりユーザーの認証確認処理および、アクセス制御処理を実行する。図中54は、アクセス制御サービス14に構成されるアクセス制御サービスAPI42を呼び出すためのアクセス制御サービスI/F54である。アクセス制御サービスI/F54は、Webアプリケーション52から利用する事ができるよう構成される。以後、上記ソフトウェアモジュールの協調により実行される一連のWebアプリケーション処理をサービス15で実行される処理と記載する。なお、サービス15で実行されるWebアプリケーション処理の詳細については後述する。図6はユーザー情報のデータ構造および、ユーザー認証時に生成する認証トークン情報のデータ構造である。ユーザー情報は、ユーザーテーブル60、ユーザーロールテーブル61で構成され、データベースサービス16にて管理されている。また、認証トークン情報は認証トークンキャッシュ63で構成され、アクセス制御サービス14のRAM23に格納される。ユーザーテーブル60は、ユーザーを識別するためのユーザーID601、秘匿情報であるパスワード602、ユーザーのデータアクセス範囲を示すユーザータイプID603、ユーザーが所属するテナントを識別するためのテナントID604から成る。なお、ユーザーIDは、ユーザー識別情報と呼ばれることもある。ユーザーロールテーブル61は、ユーザーを識別するためのユーザーID611、ユーザーに設定されているロール情報を示すロールID612から成る。認証トークンキャッシュ63は、認証トークンを識別するための認証トークンID631、ユーザーを識別するためのユーザーID632、ユーザーに設定されている全てのロールIDであるロールID配列633から成る。これにより認証トークンとロールID配列とが関連付けられて管理される。なお、認証トークンキャッシュ63のデータはアクセス制御サービス14においてユーザーの認証処理が実行され、認証が成功した時に生成される。図7はロール情報およびリソース情報のデータ構造である。ロール情報はロールテーブル70、リソース情報はリソーステーブル71で構成される。また、ロールとリソースの関係はリソースロールテーブル72で構成される。これらテーブルはデータベースサービス16にて管理されている。ロールテーブル70は、ロールを識別するためのロールID701、ロールのカテゴリを識別するためのロールカテゴリID702から成る。リソーステーブル71は、リソースを識別するためのリソースID711、リソースのカテゴリを識別するためのリソースカテゴリID712、リソースとして管理される情報である保護アイテム713、リソースに対する権限情報を示す権限714から成る。リソースロールテーブル72は、リソースを識別するためのリソースID721、ロールを識別するためのロールID722から成る。図8はテナント情報およびAPIの実行権限情報のデータ構造である。テナント情報はテナントテーブル80、APIの実行権限情報はAPI権限テーブル81で構成され、データベースサービス16にて管理されている。テナントテーブル80は、テナントを識別するためのテナントID801、テナントに属するユーザーに設定されるユーザータイプID802、テナントのカテゴリを識別するためのテナントカテゴリID803から成る。API権限テーブル81は、APIを識別するためのファンクションID811、ロールを識別するためのロールID812、およ9び、操作テナントカテゴリID813、被操作テナントカテゴリID814からなる。なお、操作テナントカテゴリID813は、API実行者が所属するテナントのカテゴリを識別するためのIDである。また、被操作テナントカテゴリID814は、API実行対象のデータが所属するテナントのカテゴリを識別するためのIDである。図6、図7、図8で説明した各データ構造に格納されるデータの処理詳細については後述する。以下、本発明の各サービスにおける処理フローについてシーケンスおよびフローチャートを用いて説明する。図9はクライアント12のWebブラウザからサービス15に対してWebリクエストを行った場合の基本シーケンスである。なお、以後、クライアント12のWebブラウザでの制御をクライアント12の制御として説明する。シーケンスS9.1において、クライアント12は、サービス15のWebサーバー51に対してWebリクエストを実行する。Webサーバー51は、フィルタリングアプリケーションであるアクセス制御エージェント53に対して、Webリクエストを通知するシーケンスS9.2。シーケンスS9.3において、アクセス制御エージェント53は、アクセス制御サービス14のアクセス制御エージェントI/F41を介してアクセス制御部43にて認証確認を行う。このとき、Webリクエストに含まれている認証トークンをアクセス制御エージェントI/F41を介してアクセス制御部43に通知する。アクセス制御部43は、通知された認証トークンが認証トークンキャッシュ63に格納されているかを検証する。シーケンスS9.3では初回アクセスであるため、通知された認証トークンは認証トークンキャッシュ63に格納されていない。そのため、認証されていないと判断しアクセス制御エージェントI/F41を介してアクセス制御エージェント53に、ログインサービス13に遷移するよう応答する。シーケンスS9.4において、アクセス制御エージェント53は、クライアント12をログインサービス13のログインアプリケーション32にリダイレクトさせる。シーケンスS9.5において、ログインアプリケーション32はログイン画面を生成し、クライアント12に提示する。シーケンスS9.6において、クライアント12は、シーケンスS9.5において生成されたログイン画面を介してユーザーからのログイン指示を受けて、その際入力されたユーザー情報をログインアプリケーション32にログイン通知する。ここで、ユーザー情報としては、ユーザーを識別するためのユーザーID、および秘匿情報であるパスワードが通知される。ログイン通知を受けたログインアプリケーション32は、シーケンスS9.7にて、アクセス制御エージェント33および、アクセス制御エージェントI/F41を介して、アクセス制御部43に対して認証リクエスト認証要求を行う。認証リクエストを受けたアクセス制御部43は認証リクエストに含まれるユーザーID,パスワードが正当であるか検証する。その際、アクセス制御部43はシーケンスS9.8にて、DBドライバ部44を介してデータベースサービス16のユーザーテーブル60に格納されているユーザーID601、パスワード602情報と比較検証する。なお、秘匿情報であるパスワード602は、例えば、非可逆なハッシュ関数を適用し、秘匿化されて格納されていることが好ましい。その場合は、通知された認証リクエストのパスワード情報をパスワード602に格納する際に適用した関数で秘匿化し、比較することで検証が行われる。シーケンスS9.8において、アクセス制御部43は、検証の結果、ユーザー情報が正当である場合は認証トークンを生成し、認証トークンキャッシュ63に格納する。その際、DBドライバ部44を介して、ユーザーロールテーブル61からユーザーIDをキーとして、ロールID612を全て取得し、ユーザーIDと共に格納する。そして、アクセス制御部43は、シーケンスS9.9にて、アクセス制御エージェントI/F41を介してアクセス制御エージェント33に生成した認証トークンを通知する。シーケンスS9.10において、アクセス制御エージェント33は、受け付けた認証トークンを付与して、クライアント12を、シーケンスS9.1にてリクエストされたWebサーバー51にリダイレクトさせる。そして、シーケンスS9.11において、Webサーバー51はシーケンスS9.2と同様に、アクセス制御エージェント53にWebリクエストを通知する。シーケンスS9.12において、アクセス制御エージェント53は、アクセス制御サービス14のアクセス制御エージェントI/F41を介してアクセス制御部43にて認証確認を行う。このとき、Webリクエストに含まれている認証トークンをアクセス制御エージェントI/F41を介してアクセス制御部43に通知する。アクセス制御部43は、通知された認証トークンが認証トークンキャッシュ63に格納されているかを検証する。通知された認証トークンは、シーケンスS9.8において認証トークンキャッシュに保存済みである。よって、シーケンスS9.12において、アクセス制御エージェント53により通知された認証トークンは認証トークンキャッシュ63に格納されていると判断される。そのため、アクセス制御部43は、認証されていると判断し、リソースアクセス可否確認を行う。リソースアクセス可否確認の処理詳細については後述する。次に、アクセス制御部43は、リソースアクセスを許可と判断した場合は、DBドライバ部44を介してユーザーテーブル60からユーザー情報を取得する。そして、アクセス制御部43は、取得したユーザー情報をアクセス制御エージェントI/F41を介してアクセス制御エージェント53に通知する。シーケンスS9.13において、アクセス制御エージェント53は、Webアプリケーション52に対してWebリクエストおよび、ユーザー情報を通知する。ユーザー情報の通知を受けたWebアプリケーション52は、不図示の業務用の画面を生成し、シーケンスS9.14にてクライアント12に提示する。そして、クライアント12は、シーケンスS9.15にてユーザーからの画面操作を受けて、シーケンスS9.16にてWebサーバー51に対して操作されたことを示すWebリクエストを通知する。シーケンスS9.17、シーケンスS9.18、およびシーケンスS9.19は、それぞれ、シーケンスS9.11、シーケンスS9.12、およびシーケンスS9.13と同様の処理であるため、説明を省く。次に、シーケンスS9.15におけるユーザーの操作に伴って、アクセス制御サービス14のアクセス制御サービスAPI42のAPIが実行されるケースとして説明する。シーケンスS9.20において、Webアプリケーション52は、アクセス制御サービスI/F54を介してアクセス制御サービスAPI42のAPIを呼び出す。その際、APIの引数として認証トークンを通知する。シーケンスS9.21において、アクセス制御サービスAPI42はAPI実行権限の確認を行う。API実行権限の確認処理詳細については後述する。API実行が許可された場合、アクセス制御サービスAPI42はAPIの処理内容に従ってアクセス制御部43に対してデータ取得をリクエストするシーケンスS9.22。その際、認証トークンを通知する。シーケンスS9.23において、アクセス制御部43はデータアクセスの可否の確認処理を行うシーケンスS9.23。データアクセスの可否の確認処理詳細については後述する。データアクセスが許可された場合、アクセス制御部43はDBドライバ部44を介してデータを取得し、シーケンスS9.24においてアクセス制御サービスAPI42へ通知する。シーケンスS9.25において、アクセス制御サービスAPI42は、取得したデータをもとにAPI応答を生成し、アクセス制御サービスI/F54を介してWebアプリケーション52に通知する。シーケンスS9.26において、Webアプリケーション52はAPI応答に従った画面を生成し、クライアント12に提示する。上記、図9を用いて説明した基本シーケンスによって、ユーザーの認証および、ユーザーのアクセス権制御処理を実行する。図10は、図9を用いて説明した基本シーケンスにおける、アクセス制御サービス14におけるアクセス制御処理フローである。以下、図9におけるシーケンスS9.20のアクセス制御サービスAPI42へのAPI呼び出しにおいて、ステップS1001が実行されるフローを説明する。アクセス制御サービスAPI42は、ステップS1001にてAPI呼び出しを受けると、ステップS1002にて通知された認証トークンの有効性を確認する。より具体的には、アクセス制御サービスAPI42は、アクセス制御部43に対して、通知された認証トークンが認証トークンキャッシュ63に格納されているかを確認する。そして、認証トークンが無効であると判断された場合認証トークンが格納されていない場合は、ステップS1003にて認証トークンが無効であるため、APIが実行できない旨を応答する。認証トークンが有効である場合、ステップS1004にて、アクセス制御サービスAPI42は、アクセス制御部43を介して認証トークンをキーにユーザーIDを取得する。そして、アクセス制御サービスAPI42は、続けてユーザーテーブル60、テナントテーブル80よりユーザー情報、テナント情報を取得する。次に、ステップS1005において、アクセス制御サービスAPI42は、DBドライバ部44を介してAPI権限テーブルから呼び出されたAPIのファンクションIDをキーに情報を取得する。アクセス制御サービスAPI42はステップS1006にて、取得したユーザー情報およびテナント情報とAPI権限情報を比較する。ステップS1007にて、アクセス制御サービスAPI42は、APIが操作する対象のテナントのカテゴリIDと、取得したテナント情報のテナントカテゴリID803とを用いて、ロールID812を取得する。そして、ユーザー情報に取得したロールIDが含まれていない場合はAPI実行を拒否し、ステップS1008にて認可エラーとして応答する。ユーザー情報に取得したロールIDが含まれている場合はAPI実行を許可し、ステップS1009にてAPIを実行する。この処理がAPI検証処理である。ステップS1010において、アクセス制御サービスAPI42は、API実行内容にリソースアクセスを含まない場合は、ステップS1011にてAPIの実行結果を生成して応答する。API実行内容にリソースアクセスが含まれる場合は、アクセス制御サービスAPI42は、ステップS1012において、アクセス制御部43に対してリソースアクセス可否確認を行う。ここでリソースとしては、データベースサービス16に格納されている情報であるデータリソースや、サービス15が提供するWebアプリケーションのURLリソースである。アクセス制御部43におけるリソースアクセス可否確認の処理は後述する。ステップS1013において、アクセス制御サービスAPI42は、アクセス制御部43におけるリソースアクセス可否確認の結果が拒否だった場合は、ステップS1008にて認可エラーとして応答する。アクセス制御サービスAPI42は、アクセス制御部43におけるリソースアクセス可否確認の結果が許可だった場合は、取得したリソース情報をもとにAPIの実行結果を生成して応答する。以下、図9におけるシーケンスS9.12、シーケンスS9.18、シーケンスS9.22におけるアクセス制御部43へのアクセス権限確認においてステップS1021が実行されるフローを説明する。また、ステップS1021は、図10におけるステップS1011のリソースアクセス可否確認においても実行される。シーケンスS9.12、シーケンスS9.18では、URLリソースに対するリソースアクセス可否確認として、また、シーケンスS9.22では、データリソースに対するリソースアクセス可否確認として、ステップS1021が実行される。ステップS1021において、アクセス制御部43は、リソースアクセス可否確認のリクエストを受け付ける。この際、リソースアクセスを実行するユーザーの認可トークン、対象のリソースカテゴリ、保護アイテム情報、および保護アイテムに対するアクションを取得する。ここで、保護アイテム情報とは、リソースカテゴリがURLリソースである場合はURL、データリソースである場合は、ユーザータイプIDおよび取得条件となる。また、アクションは、保護アイテムに対するCRUDCreate,Read,Update,Deleteから選択される。ステップS1022において、アクセス制御部43は受け付けた認証トークンが認証トークンキャッシュ63に格納されているかを確認し、有効性を検証する。検証の結果、無効であった場合はステップS1023にて認証トークンが無効である旨を通知する。検証の結果、認証トークンが有効であった場合、アクセス制御部は、受信した認証トークンに関連づけられたユーザーID632およびロールID配列633を取得するステップS1024。なお、本願ではロールIDのことをロール情報と呼ぶ場合もある。ステップS1025において、アクセス制御部43は、リソースアクセス可否確認依頼に含まれるリソースカテゴリリソース種別を特定する。URLリソースであった場合、アクセス制御部43の処理はステップS1026へ、データリソースだった場合、ステップS1027へ進む。ステップS1026、ステップS1027ではアクセス制御部43は、リソースカテゴリID、保護アイテム情報をキーとしてリソーステーブル71および、リソースロールテーブル72よりリソースに紐づいた全てのロールIDおよび権限を取得する。ステップS1028において、アクセス制御部43は、取得したロールIDおよび権限と、リクエストで受け付けた認証トークンに紐づくロールIDおよび、アクションを比較する。つまり、各テーブルの管理内容に基づいてS1028の処理が実現される。そして、ステップS1029において、アクセス制御部43は比較検証の結果、アクセス権限がない場合、つまりアクセス拒否の場合、ステップS1030にてアクセス拒否通知を行う。アクセス制御部43は比較検証の結果、アクセス権限がある場合、つまりアクセス許可の場合、ステップS1031にて対象のリソースを取得する。たとえば、リソースカテゴリがデータリソースであった場合は、指定の取得範囲を条件として、DBドライバ部44を介してデータを取得する。この際、必ず許可されたユーザータイプIDの範囲で取得データ範囲を絞り込まれる。結果、権限を保持していない他のテナントのデータを取得する事を防ぐことができる。S1028-S1029の処理が、URL検証処理、または、データ配信検証処理に相当する。ステップS1032において、アクセス制御部43は取得したリソースおよび、アクセス許可を通知する。上記、図9の基本シーケンスおよび、図10のアクセス制御フローにより、ロール定義およびロール制御という統一的な方式によって、URLリソース、データリソース、およびAPI実行権限確認を実現する事ができる。次に、図6、図7、図8で説明した各データ構造をもつテーブルに対して、データ例として図11、図12、図13を例示する。そして、サービス15に展開されるサービスを図14として例示し、具体的な業務フローとしてアクセス制御フローを図15、図16を用いて説明する。ここで説明するデータやサービスは一例であり、本発明の内容が説明した内容に制限されるものではない。図11において、111は、ユーザーテーブル60のデータ例である。次に、112はユーザーロールテーブル61のデータ例である。図12において、121はロールカテゴリの定義例である。本例では、データ管理権限を示す管理ロール、ユーザーとの利用契約を示す製品ロール、そして、データに対するアクセス範囲を示すテナントロールが定義されている。図12において、123はリソースカテゴリの定義例である。本例では、Webアクセスする対象としてのURLリソース、データベースサービス16で管理されているデータを示すデータリソースが定義されている。図12において、122はロールテーブルのデータ例である。次に124はリソースロールテーブルロール管理情報ともいうのデータ例である。そして、125はリソーステーブルのデータ例である。図13において、131はテナントカテゴリの定義例である。本例では、ユーザーとの利用契約を行う販売者が所属する販売テナント、利用者である顧客テナント、および、ユーザー本人である自身というカテゴリが定義されている。図13において、132はテナントテーブルのデータ例である。図13のテナントテーブル132は、新規ユーザーをユーザーテーブル111に追加する際に利用される。次に133はAPI権限テーブルのデータ例である。本データ例では、以下のAPIを例示している。利用契約を行ったユーザーのテナントを、販売者が作成するためのAPIであるCreateTenant。ユーザーのロール定義の設定を変更するChangeRole。および、テナントに所属するユーザーを検索するためのSearchUserというAPIを例示している。図14は、サービス15が、Webアプリケーション例として、ユーザーやユーザーのロール設定を管理するためのWebアプリケーションユーザー管理サービスとするをサービスしたときの画面フロー例である。1401は、ログインサービス13で生成されるログイン画面の例である。ユーザーが図中のユーザーIDおよびパスワードを入力のうえでログイン画面を押下し、ログイン成功およびアクセスが許可されると1402のメニュー画面に遷移する。本例では、ユーザーテーブルのデータ例111に登録されているCustomerAdmin01というユーザーでログインしたとする。1402は、ユーザー管理サービスのメニュー画面の例である。ユーザーが図中のユーザー検索リンクを押下しアクセスが許可されると、1403のユーザー検索画面に遷移する。1403は、ユーザー管理サービスのユーザー検索画面の例である。ユーザーが図中のユーザー名に検索項目を入力し検索ボタンを押下し、SearchUserAPIの実行権限が許可されると、ユーザー検索が実行され、1404の検索結果画面に遷移する。ここで、検索項目としてはというワイルドカード全件検索指定したとする。1404は、ユーザー管理サービスのユーザー検索画面における検索結果画面の例である。ここでは、ユーザーテーブルのデータ例111に、CustomerAdmin01が所属するTA00000002テナントのユーザーが全て表示される。図15は、図14の画面フローに従ってユーザーが操作した場合のシーケンスである。シーケンスS15.1において、クライアント12はサービス15のメニュー画面1402へWebリクエストを行う。シーケンスS15.2において、サービス15はアクセス制御エージェントI/F41に対して認証確認を行う。ここで認証確認フローは図9のシーケンスS9.1-S9.3に対応する。シーケンスS15.3において、サービス15は、クライアント12をログインサービス13にリダイレクトさせる。そして、シーケンスS15.4において、ログインサービス13はログイン画面1401を提示する。これらの処理は、図9のシーケンスS9.4-S9.5に対応する。シーケンスS15.5において、ユーザーはユーザーID:CustomerAdmin01としてログイン操作を行う。ログイン操作を受けたログインサービス13はアクセス制御エージェントI/F41に対して認証処理を依頼する。これらの処理は、図9のシーケンスS9.6に対応する。シーケンスS15.6における認証処理については、図9のシーケンスS9.7にて説明済みであるため省略する。ここで、認証成功した場合、アクセス制御部43では、認証トークンキャッシュ63に、生成した認証トークンのID、ユーザーID:CustomerAdmin01および、ロールIDを格納する。ここで、ロールIDとしてはユーザーロールテーブルのデータ例112に記載のCustomerAdmin、Customer、TA00000002、Provisioningが格納される。認証を受けたログインサービス13は、認証トークンを付与してシーケンスS15.7にて、クライアント12をサービス15のメニュー画面1402へリダイレクトさせる。シーケンスS15.8において、サービス15はアクセス制御エージェントI/F41を介してアクセス制御部43に対して認証確認、アクセス権限確認、およびユーザー情報取得を行う。アクセス制御部43では、認証トークンキャッシュ63に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーIDおよびロールID配列を取得する。今回は格納されているため、ユーザーID:CustomerAdmin01、ロールID配列CustomerAdmin、Customer、TA00000002、Provisioningが取得される。次に、アクセス制御部43では、図10におけるステップS1021が実行される。このとき、対象のリソースとしてhttp:xxx.com/menu/xxx.htmlが渡されるとする。これは、例えば、ユーザーが上記アドレスをブラウザに入力することにより実現される。このリソースはリソーステーブルのデータ例125のリソースID:R00000001に格納されているデータと一致する。そして、リソースID:R0000001は、リソースロールテーブルのデータ例124にて、ロールID:Customerに割り当てられている。アクセス制御部43は図10におけるステップS1028にて、ロールID:Customerが、取得したロールID配列に含まれるかを確認する。具体的には、認証トークンキャッシュ63から、認証トークンに関連付けられたロール情報が決定される。その決定されたロール情報が、取得したロールID配列に含まれるかが確認される。つまり、アクセス制御部43が、リソースカテゴリとしてURLである場合、そのURLに一致するロールIDを図12のリソースロールテーブル124から取得する。そしてリソースロールテーブル124から取得されたロールID認証トークンに割り当てられたロールID配列とに基づいて、アクセスを許可するか否かを判定する。なお、この処理は、他の段階でも同様に実行される。今回のデータ例ではロールID配列にCustomerが含まれているため、アクセス制御部43は、アクセス許可としてユーザーテーブルのデータ例111から情報を取得し、サービス15に通知する。シーケンスS15.9にてサービス15はクライアント12にメニュー画面1402を提示する。ここまでは、図14におけるメニュー画面1402の表示、画面1402におけるAPIの実行、リソースデータの提供という3段階3レイヤーの第1段階第1レイヤーの処理となる。次に、メニュー画面1402にてユーザーがユーザー検索リンクを押下した場合のシーケンスを説明する。シーケンスS15.10において、ユーザー検索が選択されると、サービス15はシーケンスS15.11にてアクセス制御エージェントI/F41を介して、アクセス制御部43に認証確認、アクセス権限確認、ユーザー情報取得を依頼する。アクセス制御部43では、認証トークンキャッシュ63に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーIDおよびロールID配列を取得する。今回は格納されているため、ユーザーID:CustomerAdmin01、ロールID配列CustomerAdmin、Customer、TA00000002、Provisioningが取得される。次に、アクセス制御部43では、図10におけるステップS1021が実行される。このとき、対象のリソースとしてhttp:xxx.com/search/xxx.htmlが渡されるとする。このリソースはリソーステーブルのデータ例125のリソースID:R00000002に格納されているデータと一致する。そして、リソースID:R0000002は、リソースロールテーブルのデータ例124にて、ロールID:Provisioningに割り当てられている。アクセス制御部43は図10におけるステップS1028にて、ロールID:Provisioningが、取得したロールID配列に含まれるかを確認する。今回のデータ例ではロールID配列にProvisioningが含まれているため、アクセス制御部43は、アクセス許可としてユーザーテーブルのデータ例111から情報を取得し、サービス15に通知する。シーケンスS15.12にてサービス15はクライアント12にユーザー検索画面1403を提示する。ここまでは、図14におけるメニュー画面1402の表示、画面1402におけるAPIの実行、リソースデータの提供という3段階3レイヤーの第2段階第2レイヤーの処理となる。次に、ユーザー検索画面1403にてユーザーが検索項目としてワイルドカードであるを入力し、ユーザー検索ボタンを押下した場合のシーケンスを説明する。シーケンスS15.13において、ユーザー検索が実行されると、サービス15はシーケンスS15.14において、アクセス制御サービスAPI42に対して、SearchUserAPIを実行する。この際、認証トークンを通知する。シーケンスS15.15において、アクセス制御サービスAPI42では、図10におけるステップS1001が実行される。このとき、ユーザー検索が実行されたため、対象のAPIとしてSearchUserが渡される。アクセス制御サービスAPI42は、認証トークンを検証し、ユーザーIDおよびロールID配列を取得する。次に、図10におけるステップS1005が実行され、API権限テーブルのデータ例133からファンクションID:SearchUserが取得される。そして、ロールID配列のロールID:CustomerAdmin、Customerが該当する二つのデータが取得される。アクセス制御サービスAPI42では、ステップS1006において、API権限テーブルから取得したデータより、操作者のテナントカテゴリID:CustomerTenantにおける、SearchUserAPIの実行権限を以下と判断する。被操作テナントカテゴリ:CustomerTenant、Selfの範囲で許可される。シーケンスS15.16において、アクセス制御サービスAPI42は、図10におけるステップS1010にて、データリソースへのアクセスとしてアクセス制御部43にリソースアクセス可否確認依頼を実行する。その際、認証トークンおよび、データ取得範囲として、ユーザーデータテーブルに対するを通知する。シーケンスS15.17において、アクセス制御部43では、認証トークンキャッシュ63に認証トークンが格納されているかを確認し、格納されている場合は、ユーザーIDおよびロールID配列を取得する。今回は格納されているため、ユーザーID:CustomerAdmin01、ロールID配列CustomerAdmin、Customer、TA00000002、Provisioningが取得される。次に、アクセス制御部43では、図10におけるステップS1021が実行される。このとき、対象のリソースとしてCustomerTenant、Selfが渡されるとする。アクセス制御部43において、データアクセス可能な範囲は、操作者が所属するテナントまでであるため、保護アイテムは、ユーザーテーブルデータ例111に登録されているTY00000002となる。このリソースはリソーステーブルのデータ例125のリソースID:R00000004に格納されているデータと一致する。そして、リソースID:R0000004は、リソースロールテーブルのデータ例124にて、ロールID:TA00000002に割り当てられている。アクセス制御部43は図10におけるステップS1028にて、ロールID:TA00000002が、取得したロールID配列に含まれるかを確認する。今回のデータ例ではロールID配列に含まれているため、アクセス制御部43は、TY00000002の範囲でアクセス許可としてユーザーテーブルのデータ例111から情報を取得する。その際、データ範囲がワイルドカードであるため、TY00000002の範囲でユーザーデータテーブルから取得可能な全データが取得され、シーケンスS15.18にてアクセス制御サービスAPI42に通知する。シーケンスS15.19において、アクセス制御サービスAPI42は、SearchUserAPIの応答として、取得したユーザー情報をサービス15に応答する。シーケンスS15.20において、サービス15は取得したユーザー情報から検索結果画面1404を生成してクライアント12に提示配信する。ここまでは、図14におけるメニュー画面1402の表示、画面1402におけるAPIの実行、リソースデータの提供という3段階3レイヤーの第3段階第3レイヤーの処理となる。本願では、全ての段階全てのレイヤーの実行確認をロールにて行うことにより、開発、および運用、保守のコストを軽減することができる。上記、図15のシーケンスおよび、図10のアクセス制御フローにより、ロール定義およびロール制御という統一的な方式によって、URLリソース、データリソース、およびAPI実行権限確認を実現する事ができる。図16において161はユーザー管理サービスのメニューでロール管理を選択し、不図示のロール設定画面よりユーザーのロール設定を変更した場合に実行されるChangeRoleAPIの実行可否を定義するロール操作可否テーブルのデータ例である。図15のシーケンスS15.15において、アクセス制御サービスAPI42は、API実行が許可となった場合に、以下の処理を行う。ロール操作可否テーブルから、API実行者のロールIDで絞り込みを行う。ロール設定の変更対象であるロールIDから、ロールカテゴリIDを取得し、被操作ロールカテゴリIDにて絞り込みを行う。そこで、被操作ロールカテゴリがである場合は、可否を確認する。最後に、ロールIDで絞り込みを行い、結果である場合は、可否を確認する。ロールIDが存在しない場合は、拒否と判断する。そして、可否の確認結果、Allowである場合はAPIを実行し、Denyである場合はAPI実行を拒否する。本発明では、ロール操作可否テーブルのデータ例161の定義1611に示している通り、被操作ロールカテゴリIDがManagementRoleである場合、操作ロールIDがAdminロールをもつ必要がある。本発明では、ロール操作可否テーブルのデータ例161の定義1612に示している通り、被操作ロールID:Customerは誰からも操作されないよう定義されている。これにより、他のテナントカテゴリIDのロールIDを誤って設定する事を防ぐことができる。すなわち、他のテナントカテゴリIDのURLリソースに対するアクセス制限や、APIの実行制限を行う事ができる。本発明では、ロール操作可否テーブルのデータ例161の定義1614に示している通り、被操作ロールカテゴリIDがTenantRoleである場合、どのような操作ロールID、被操作ロールIDであっても可否をDenyと設定する。これにより、TenantRoleカテゴリのロールを、所属外のテナントに誤って設定する事を防ぐことができる。すなわち、自身が所属するテナント外のテナントデータに対するアクセス制限をかけることが可能となる。本願の処理は認証システムにより実行される。なお、認証システムは、1台の情報処理装置例えば、サーバーで構成されても良いし、複数台の情報処理装置例えば、サーバーで構成されても良い。"