サーバーシステム、その制御方法、およびプログラム。
【課題】 複数のサービスが連携しているクラウド認証サービスにおいて、各サービスがログを出力する間隔が異なり、かつ各サービスのログを出力する間隔を変更できない場合がある。
【解決手段】 連携している全てのサービスで最もログ出力間隔が長いサービスのログが出力された時点で、連携している全てのサービスのログを収集する。その後収集したログのなかで、ログ出力時間が最も古い時刻であるものを調べ、全ログの中からその時刻までのログを抽出し、認証サービスのログとして保存する。
【解決手段】 連携している全てのサービスで最もログ出力間隔が長いサービスのログが出力された時点で、連携している全てのサービスのログを収集する。その後収集したログのなかで、ログ出力時間が最も古い時刻であるものを調べ、全ログの中からその時刻までのログを抽出し、認証サービスのログとして保存する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサービスからなる認証サービスを提供するサーバーシステム、その制御方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、クラウドサービスとしてインターネット上にサービスを公開するビジネス展開がされてきている。クラウドサービスの特徴の一つに、一つのサービスを複数の契約者に対して提供するマルチテナントサービスが挙げられる。マルチテナントサービスは、１つのシステム上で複数の契約者を管理するために、異なる契約者のデータを分離し、それらのデータを参照できないようにしてセキュリティを担保している。
特許文献１では、ユーザーの属性とデータの属性にテナントＩＤを持たせ、ユーザーからの要求に対して、テナントＩＤが一致するデータに対してのみアクセスできるようにアプリケーションで制御することで、マルチテナントを実現している。
またクラウドサービスにおいて、複数のサービスを連携させ、サービス機能の強化を行う展開がある。既存のサービスを流用する事で、容易に新たなサービスの提供を行うことが出来る。このように複数のサービスを連携させて一つのサービスとして提供する場合、提供しているサービスのログの内容には、連携している各サービスが出力するログの内容を含む必要がある。このログには、要求を受け取り処理したことが示されている。
複数のサービスが出力するログをまとめる方法として、特許文献のような方法がある。参考文献２では、サービスが配置されているサーバーごとにログ送信間隔を設定し、その間隔で各サーバーがログをログ収集サーバーへと送信することにより、複数のサービスが出力するログをまとめている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−０２６６５３
【特許文献２】特開２００４−２９５３０３
【発明の概要】
【発明が解決しようとする課題】
【０００４】
既存のサービスを流用して新たなサービスを提供する際に、既存のサービスに対してカスタマイズできる部分が限られているため、既存のサービスを提供するアプリケーション内部の処理を修正出来ない場合がある。特に各サービスがそれぞれ異なる間隔でログを出力していて、既存のサービスを提供するアプリケーションのログ出力間隔を変更できない場合、ある時間においてログを取得した際、サービス全体のログとしては不完全な状態、即ち、一部のログが不足している状態になりうる。この状態は、認証サービスのようなサービス内での処理順序が重要なサービスにおいて問題となる。
【０００５】
例えば、ログインを受け付けるログインサービスがあり、このサービスは内部処理が修正出来ず、ある間隔でしかログを出力できないものとする。ここで、このログインサービスを利用する機能を新規で作成し連携させ、認証サービスを構築したとする。さらに、その新機能はサービス監視のために常時ログを出力すると仮定する。この場合、ログインサービスが出力するログの出力が遅いため、認証サービスにログインしたというログが出力されていないが、認証サービスを利用しているログが出力されている事態が起きうる。
【０００６】
監視者がこのようなログを見た場合、ログインしたというログがないにもかかわらず、認証サービスが利用されたと認識するので、サービスが不正利用されている可能性を疑うであろう。
【０００７】
その他の課題としては次の様な事が考えられる。一定時間経過後に認証サービスにログインしたというログが出力されるので、監視者は常にログを時系列順に確認することが困難となり、サービスの監視や管理が困難となる。
【０００８】
その他の課題としては次の様な事が考えられる。ログインサービスが出力するログの出力が早い場合は、ログアウトしたログが出力された後で、操作内容のログが出力されることが起きうる。この状態でログ監視を行う場合、監視者は操作内容のログが出力されるたびに過去のログから操作者がログアウトしていないかを確認し続ける必要がある。
【０００９】
その他の課題としては次の様な事が考えられる。これまでクラウドサービスとして提供していなかったサービスをクラウドサービスと連携させ、クラウドサービスに対応させる事が考えられる。しかし、マルチテナントに対応していないサービスから出力されるログには、テナント情報が出力されない場合がある。この場合、出力されているログがどのテナントに属するユーザーの操作なのかが判断出来ないため、ログとして不十分となる。
【００１０】
例えば、ログインを受け付ける認証サービスがマルチテナントに対応しておらず、内部処理も修正できないものとする。一方、その認証サービスを利用する機能がマルチテナントに対応しているものとする。ユーザーの属性情報の一つにテナント情報を持たせて、機能利用時にテナント情報を取得して判断などをすることで、マルチテナントを実現することが出来る。この場合、操作時に出力されるログにテナント情報を出力することは出来るが、ログインした際のログにはテナント情報が出力されない。
【課題を解決するための手段】
【００１１】
本発明の一実施形に係るサーバーシステムは、ウェブサービスを提供するウェブサービス部と、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証ＡＰＩサービス部とから構成され、前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とする。
【発明の効果】
【００１２】
本発明により、異なる間隔でログを出力するサービスが連携しているサービスにおいて、ある時点で全てのサービスが出力したログを取得できる。
また、その他の効果として、マルチテナントに対応していないサービスが出力するログを、マルチテナントに対応したログとすることが出来る。
【図面の簡単な説明】
【００１３】
【図１】システム構成図。
【図２】各サーバー、クライアント端末のハードウェア構成図。
【図３】認証サービス利用サービスのソフトウェアモジュールの構成図。
【図４】認証ＡＰＩサービスのソフトウェアモジュールの構成図。
【図５】認証・認可サービスのソフトウェアモジュールの構成図。
【図６】（Ａ）認証サービス上で管理されるユーザー情報のデータ構造例。 （Ｂ）認証サービス上で管理されるユーザー認証情報のデータ構造例。
【図７】認証サービスのログ収集のフローチャート。
【図８】（Ａ）認証ＡＰＩサービスが出力するログ情報例。 （Ｂ）認証・認可サービスが出力するログ情報例。 （Ｃ）認証・認可サービスが出力したログを認証サービスのログに変換したログ情報例。
【図９】認証サービスのログをマルチテナントに対応させて収集する際のフローチャート。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【実施例１】
【００１５】
［システム構成］
図１は、本発明の実施例のシステム構成を示すブロック図である。
【００１６】
図中１０は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１０）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。図中１１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１）である。また図中１２はファイアーウォールである。
【００１７】
図中１３はクライアント１７からの要求を受け、認証サービスを利用してウェブサービスを提供するサービス提供サーバー１３である。図中１４は、認証サービスを利用するサービスからの要求を受け、認証・認可サーバーへと処理を行うＡＰＩ（Ａｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する認証ＡＰＩサーバー１４であり、ＡＰＩを利用した呼び出しを受けることで所定の機能を動作させる。図中１５は認証ＡＰＩサービスや認証サービスを提供するサービスからの要求を受け、ユーザー認証や認証情報管理、ユーザーの認可を行う認証・認可サーバー１５である。
【００１８】
図中１６は認証・認可サービス、認証ＡＰＩサービス、認証サービスを利用するサービスが連携している認証サービスである。なお、認証サービスを利用するサービスは不図示の他のサービスであってもよく、その場合、認証サービスは認証・認可サービスと認証ＡＰＩサービスとが連携するサービスとなる。なお、認証サービスがサーバーシステムに相当し、サーバーシステムは１台から構成されるシステムであっても、複数台から構成されるシステムであっても良い。認証サービス１６を提供するサーバーシステムの運用方法について特に制限はない。よって、認証・認可サーバーを認証サービス部と称し、認証ＡＰＩサーバーを認証ＡＰＩサービス部と称し、サービス提供サーバーをサービス提供サービス部、またはウェブサービス部と称する。
【００１９】
図中１７はＬＡＮ１１およびＷＡＮ１０を介して各サーバーに対してＷｅｂリクエストを発行するクライアント端末１７であり、より具体的にはＷＷＷを参照可能なＷｅｂブラウザを備えたクライアント端末である。
【００２０】
［ハードウェア構成］
図２は、図１中の認証・認可サーバー１３、認証ＡＰＩサーバー１４、サービス提供サーバー１５、あるいはクライアント端末１７のハードウェア構成を示すブロック図である。図２に示されるハードウェア構成図は一般的な情報処理装置及び出力デバイスのハードウェア構成図に相当するものとし、本実施形態の各情報端末、サーバーは一般的な情報処理装置のハードウェア構成を適用できる。
【００２１】
図２において、ＣＰＵ２０は、ＲＯＭ２２に記憶された、或いはＨＤＤ２３からＲＡＭ２１にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２１は、ＣＰＵ２０の主メモリ、ワークエリア等として機能する。入力装置２４は、不図示のキーボードや不図示のポインティングデバイスからのキー入力を制御する。出力装置２５は、不図示の各種ディスプレイの表示を制御する。ＨＤＤ２３は、各種データを記憶する外部メモリ、例えばハードディスクやフラッシュメモリなどの永続記憶装置である。ネットワークインターフェース２６はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００２２】
［ソフトウェア構成］
図３は、本発明の実施形態に係るサービス提供サーバー１３上で動作する、認証サービス利用サービス３０のソフトウェアモジュールの構成図である。
【００２３】
Ｗｅｂアプリケーション３０１はＷｅｂからのリクエストを受け付けるＷｅｂインタフェースを備えており、クライアント１７が備えるＷｅｂブラウザからのリクエストに対して不図示の画面を生成して応答する。Ｗｅｂアプリケーション３０１は認証サービスへの処理要求を受けると、認証ＡＰＩＩ／Ｆ３０２を利用して、認証ＡＰＩサービス４０へと処理要求を行う。
【００２４】
エージェント部３０３は、Ｗｅｂアプリケーション３０１に処理要求が来た際に、その要求をしたユーザーの認証状態を確認する。要求者が認証されていなかった場合や認証の有効期限が切れていた場合、Ｗｅｂアプリケーション３０１に認証要求画面を作成、表示させて、認証を要求する。ここで、本発明では認証方式として、ユーザーを特定するユーザーＩＤおよびパスワードを認証情報として登録しておき、認証リクエストで取得した情報とのマッチングを行う方式として説明する。ただし、この認証方式に制限するものではなく、電子証明書を確認する方式など、他の認証方式でも実現可能である。エージェント部３０３はユーザーＩＤおよびパスワードを取得すると、認証・認可サービス５０に対して認証を要求する。認証に成功した場合、認証状態を管理する認証トークンを返す。
【００２５】
図４は、認証ＡＰＩサーバー上で動作する、認証ＡＰＩサービス４０のソフトウェアモジュールの構成図である。
【００２６】
認証ＡＰＩＩ／Ｆ４０１は、他のサービスから認証ＡＰＩへの要求を受け取る。他のサービスとは、例えば、サービス提供サーバー１３が提供する認証サービス利用サービス３０からの要求である。ＡＰＩ処理部４０２は認証ＡＰＩＩ／Ｆ４０１によって受け取った要求に基づいて処理を行い、必要に応じて通信部４０３を介して認証・認可サービス５０が管理する情報を取得し、その要求に応える。また、ＡＰＩ処理部４０２で行った処理の内容はリアルタイムでログに出力され、認証ＡＰＩサービス４０のログとして認証ＡＰＩサーバー１４内の認証ＡＰＩサービスログフォルダに保存される。即ち、ＡＰＩ処理部４０２での処理が完了した時点でログが出力される。認証ＡＰＩサービスは、第１の間隔（ＡＰＩ処理部４０２での処理が完了した時点で出力されるので、第１の間隔とは処理が完了する間隔のことを指す）でログを主力する
ログ処理部４０４は、認証サービスとして連携する全てのサービスの中で、最も出力間隔が長いサービスのログが出力された時点で起動する。ログ処理部４０４は起動すると、上記認証ＡＰＩサービス４０のログを認証サービス１６の一時ログとして認証ＡＰＩサーバー１４内の認証サービス一時ログフォルダに移動する。また同時に通信部４０３を介して認証・認可サービス５０へとログ取得要求を行い、取得したログを認証サービス１６の一時ログとして認証サービス一時ログフォルダに保存する。その後、認証サービス一時ログフォルダ内のログを確認し、ログ出力時間で最も古い時刻までのログを抽出し、その時刻までのログを認証サービス１６のログとして認証サービスログフォルダに移動する。例えば、１時間ごとにログを出力するサービスと４５分ごとにログを出力するサービスが連携していた場合には、１時間毎にログを収集する。そして１時間ごとに出力するサービスが１３；００まで、４５分ごとに出力するサービスが１２：４５までのログが出力されていた場合、１２：４５までのログをサービス全体のログとして保存する。換言すれば、あるサービス部がログを出力した時点から最も短い間隔が経過するまでに出力されたログを認証ログとして出力する。
【００２７】
なお、本処理部の機能は認証ＡＰＩサーバー以外の不図示のログ収集サーバーにあってもよい。その場合、ログ処理部４０４は外部サービスからの要求を受け、認証ＡＰＩサービスのログを取得し、外部サービスへと送信する処理を行う。
【００２８】
図５は、認証・認可サービス上で動作する、認証・認可サービス５０のソフトウェアモジュールの構成図である。
【００２９】
設定部５０１は、通信Ｉ／Ｆ５０３を介してユーザー情報の設定要求を受け、認証情報記憶部５０５の情報の設定を行う。
認証・認可部５０２は、通信Ｉ／Ｆ５０３やエージェント通信Ｉ／Ｆ５０４を介して認証・認可要求を受け、認証情報記憶部５０５の情報を利用して認証および認可を行う。認証・認可部５０２は認証に成功した場合、認証トークンを発行し、認証情報（ユーザーＩＤ・パスワード）と関連付けて認証情報記憶部５０５に保存し管理する。また、認証・認可部５０２での処理内容はログとして１時間毎に出力され、認証・認可サービス５０のログとして認証・認可サーバー１５内の認証・認可サービスログフォルダに保存される。認証・認可サービス５０がログを出力する間隔が第２の間隔に相当し、第２の間隔は第１の間隔よりも長いものとする。ログ処理部５０６は、通信Ｉ／Ｆ５０３を介してログ取得要求を受け付け、認証・認可サービスログフォルダ内のログを送信する。なお、認証トークンを有する装置が、ウェブサービス部が提供するウェブサービスを利用する際、認証情報を入力することなく利用可能となる。認証トークンは、利用の制限が設けられた認可トークンであっても良い。
【００３０】
［データ構造］
図６は認証情報記憶部５０５にて管理されているユーザー認証情報の例である。
【００３１】
図６（Ａ）は、ユーザー認証情報のデータ構造の一例であり、ユーザーを特定するためのユーザーＩＤ６０１とパスワード６０２、およびユーザー属性が管理されている。ユーザー属性は、ユーザーが所属するテナント情報を示すテナントＩＤ６０３とユーザーの権限情報６０４、その他のユーザー属性情報６０５からなる。
図６（Ｂ）は、ユーザーの認証状態を管理する認証トークン情報の一例であり、ユーザーを特定するユーザーＩＤ６１１および、ユーザーが認証されたことを示すトークン６１２からなる。
【００３２】
［フローチャート］
以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。
【００３３】
図７は、認証ＡＰＩサービス４０および認証・認可サービス５０が連携している認証サービス１６において、認証サービス１６のログとして認証ＡＰＩサービス４０と認証・認可サービス５０のログを集める際の処理フローである。
【００３４】
以下のフローにおいて、認証ＡＰＩサービス４０はリアルタイムにログを出力し、認証・認可サービス５０は１時間ごとにログを出力するものとする。そのため、認証ＡＰＩサービス４０のログ処理部４０４は１時間ごとに起動するものとする。
【００３５】
ログ処理部４０４が起動すると、ステップＳ７０１、Ｓ７０２において認証ＡＰＩサービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップＳ７０３にて対応するログを認証サービス一時ログフォルダに移動する。
また、ログ処理部４０４は起動時にステップＳ７０４にて、連携している認証・認可サービスのログを要求する。認証・認可サービス５０のログ処理部５０６は、ステップＳ７０５にて認証ＡＰＩサービスからのログ要求を受け付けると、ステップＳ７０６で認証・認可サービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップＳ７０７にて対応するログをログ送信用のフォルダに移動する。その後ステップＳ７０８にて、ログ送信用フォルダ内のログを認証ＡＰＩサービスへと送信する。
【００３６】
認証ＡＰＩサービスのログ処理部は、ステップＳ７０９で認証・認可サービスのログを受信すると、ステップＳ７１０にて受信したログを認証サービス一時ログフォルダに移動する。
【００３７】
全てのサービスのログを取得すると、ステップＳ７１１にて、ログ出力時間が最も古いログを調べ、その時刻までに出力されたログを抽出する。なお、過去に抽出されずに残っていたログも抽出対象とする。その後ステップＳ７１２にて、抽出されたログを認証サービス１６のログとして、認証サービスログフォルダへと移動する。認証サービスログフォルダへ移動する際、第２の間隔毎に移動することとするが、第２の間隔よりも長い間隔で移動させても良い。なぜなら、ある期間内に出力された、認証ＡＰＩサービス部により出力されたログと、認証サービス部により出力されたログとが漏れなく提供されるからである。
【００３８】
以上のフローにより、異なるタイミングでログを出力するサービスが連携している場合に、全てのサービスが出力したある時間までのログを、欠けることなくまとめることが出来る。
【実施例２】
【００３９】
次に、本発明を実施するための第２の形態について図面を用いて説明する。
【００４０】
第１の実施例においては、連携しているサービスが異なる間隔でログを出力する場合に、ある時間までに全てのサービスが出力するログを不足なく集めることができた。本実施例では、第１の実施例において、連携しているサービスの中にマルチテナントに対応していないサービスが存在した場合にログを収集する方法を説明する。なお、本実施例においては、第１の実施例と同一部分に関する説明は省略し、その差異についてのみ説明する。
【００４１】
［データ構造］
図８は認証ＡＰＩサービス、認証・認可サービスにおいて出力されるログ情報の例と、第二の実施形態に基づいて変換されたログ情報の例を示す。
【００４２】
図８（Ａ）は、マルチテナントに対応している認証ＡＰＩサービスが出力するログ情報である。処理が実行された日時と実行者の情報および処理内容からなる。実行者の情報には、実行者を表すユーザーＩＤと、実行者のテナント情報を表すテナントＩＤが含まれて記載されている。
一方、図８（Ｂ）は、マルチテナントに対応していない認証・認可サービスが出力するログ情報である。図８（Ａ）と同様に処理が実行された日時と実行者情報、処理内容からなるが、マルチテナントに対応していないため、テナント情報が記載されたログは出力されない。
図８（Ｃ）は、図８（Ｂ）に示した認証・認可サービスが出力するログ情報を、第二の実施例に基づいて変換したログ情報である。図８（Ｂ）のログ情報にユーザーのテナント情報を表すテナントＩＤが追加されたログとなる。
【００４３】
［フローチャート］
以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。
【００４４】
図９は、認証ＡＰＩサービスおよび認証・認可サービスが連携している認証サービスにおいて、ログを集める際の処理フローである。
【００４５】
以下のフローにおいて、認証ＡＰＩサービス４０はマルチテナントに対応しており、認証・認可サービス５０はマルチテナントに対応していないサービスとする。また、認証・認可サービス５０上のユーザー情報には、テナント情報がユーザーの属性情報の一つとして管理されており、認証ＡＰＩを用いて取得できるものとする。
【００４６】
ステップＳ７０１からステップＳ７１０までは、図７と同じ処理である。
【００４７】
認証ＡＰＩサービスのログ処理部は、ステップＳ７１０で認証・認可サービスのログを受け取ると、ステップＳ９０１でそのログを１件読み込む。ログ処理部はステップＳ９０２にて、ログに含まれるユーザー情報を利用してユーザーのテナントＩＤ情報取得要求を行う。
【００４８】
認証・認可サービスの設定部５０１は、ステップＳ９０３にてテナントＩＤ情報取得要求を受けると、ステップＳ９０４でユーザー属性からテナント情報を表すテナントＩＤを取得する。その後ステップＳ９０５にて取得したテナント情報を認証ＡＰＩサービスへと返す。
【００４９】
認証ＡＰＩサービスはステップＳ９０６にてテナント情報を受け取ると、ステップＳ９０７にてログにテナント情報を追記し、ログ情報が補完され、補完情報が追加済みのログとしてログ情報を保存する。その後、全てのログにテナント情報を追加するまで、ステップＳ９０１からステップＳ９０７を繰り返す。こうして全てのログにテナント情報を追加した後で、ステップＳ７１１およびＳ７１２を行い、認証サービス１６のログを取得する。
【００５０】
以上のフローにより、マルチテナントに対応していないサービスが出力するログにテナント情報を追加して、マルチテナントに対応したログとすることができる。
【符号の説明】
【００５１】
１０ ＷＡＮ
１１ ＬＡＮ
１２ ファイアーウォール
１３ サービス提供サーバー
１４ 認証ＡＰＩサーバー
１５ 認証・認可サーバー
１６ 認証サービス
１７ クライアント端末
３０ 認証サービス利用サービス
４０ 認証ＡＰＩサービス
５０ 認証・認可サービス
【技術分野】
【０００１】
本発明は、複数のサービスからなる認証サービスを提供するサーバーシステム、その制御方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、クラウドサービスとしてインターネット上にサービスを公開するビジネス展開がされてきている。クラウドサービスの特徴の一つに、一つのサービスを複数の契約者に対して提供するマルチテナントサービスが挙げられる。マルチテナントサービスは、１つのシステム上で複数の契約者を管理するために、異なる契約者のデータを分離し、それらのデータを参照できないようにしてセキュリティを担保している。
特許文献１では、ユーザーの属性とデータの属性にテナントＩＤを持たせ、ユーザーからの要求に対して、テナントＩＤが一致するデータに対してのみアクセスできるようにアプリケーションで制御することで、マルチテナントを実現している。
またクラウドサービスにおいて、複数のサービスを連携させ、サービス機能の強化を行う展開がある。既存のサービスを流用する事で、容易に新たなサービスの提供を行うことが出来る。このように複数のサービスを連携させて一つのサービスとして提供する場合、提供しているサービスのログの内容には、連携している各サービスが出力するログの内容を含む必要がある。このログには、要求を受け取り処理したことが示されている。
複数のサービスが出力するログをまとめる方法として、特許文献のような方法がある。参考文献２では、サービスが配置されているサーバーごとにログ送信間隔を設定し、その間隔で各サーバーがログをログ収集サーバーへと送信することにより、複数のサービスが出力するログをまとめている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−０２６６５３
【特許文献２】特開２００４−２９５３０３
【発明の概要】
【発明が解決しようとする課題】
【０００４】
既存のサービスを流用して新たなサービスを提供する際に、既存のサービスに対してカスタマイズできる部分が限られているため、既存のサービスを提供するアプリケーション内部の処理を修正出来ない場合がある。特に各サービスがそれぞれ異なる間隔でログを出力していて、既存のサービスを提供するアプリケーションのログ出力間隔を変更できない場合、ある時間においてログを取得した際、サービス全体のログとしては不完全な状態、即ち、一部のログが不足している状態になりうる。この状態は、認証サービスのようなサービス内での処理順序が重要なサービスにおいて問題となる。
【０００５】
例えば、ログインを受け付けるログインサービスがあり、このサービスは内部処理が修正出来ず、ある間隔でしかログを出力できないものとする。ここで、このログインサービスを利用する機能を新規で作成し連携させ、認証サービスを構築したとする。さらに、その新機能はサービス監視のために常時ログを出力すると仮定する。この場合、ログインサービスが出力するログの出力が遅いため、認証サービスにログインしたというログが出力されていないが、認証サービスを利用しているログが出力されている事態が起きうる。
【０００６】
監視者がこのようなログを見た場合、ログインしたというログがないにもかかわらず、認証サービスが利用されたと認識するので、サービスが不正利用されている可能性を疑うであろう。
【０００７】
その他の課題としては次の様な事が考えられる。一定時間経過後に認証サービスにログインしたというログが出力されるので、監視者は常にログを時系列順に確認することが困難となり、サービスの監視や管理が困難となる。
【０００８】
その他の課題としては次の様な事が考えられる。ログインサービスが出力するログの出力が早い場合は、ログアウトしたログが出力された後で、操作内容のログが出力されることが起きうる。この状態でログ監視を行う場合、監視者は操作内容のログが出力されるたびに過去のログから操作者がログアウトしていないかを確認し続ける必要がある。
【０００９】
その他の課題としては次の様な事が考えられる。これまでクラウドサービスとして提供していなかったサービスをクラウドサービスと連携させ、クラウドサービスに対応させる事が考えられる。しかし、マルチテナントに対応していないサービスから出力されるログには、テナント情報が出力されない場合がある。この場合、出力されているログがどのテナントに属するユーザーの操作なのかが判断出来ないため、ログとして不十分となる。
【００１０】
例えば、ログインを受け付ける認証サービスがマルチテナントに対応しておらず、内部処理も修正できないものとする。一方、その認証サービスを利用する機能がマルチテナントに対応しているものとする。ユーザーの属性情報の一つにテナント情報を持たせて、機能利用時にテナント情報を取得して判断などをすることで、マルチテナントを実現することが出来る。この場合、操作時に出力されるログにテナント情報を出力することは出来るが、ログインした際のログにはテナント情報が出力されない。
【課題を解決するための手段】
【００１１】
本発明の一実施形に係るサーバーシステムは、ウェブサービスを提供するウェブサービス部と、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証ＡＰＩサービス部とから構成され、前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とする。
【発明の効果】
【００１２】
本発明により、異なる間隔でログを出力するサービスが連携しているサービスにおいて、ある時点で全てのサービスが出力したログを取得できる。
また、その他の効果として、マルチテナントに対応していないサービスが出力するログを、マルチテナントに対応したログとすることが出来る。
【図面の簡単な説明】
【００１３】
【図１】システム構成図。
【図２】各サーバー、クライアント端末のハードウェア構成図。
【図３】認証サービス利用サービスのソフトウェアモジュールの構成図。
【図４】認証ＡＰＩサービスのソフトウェアモジュールの構成図。
【図５】認証・認可サービスのソフトウェアモジュールの構成図。
【図６】（Ａ）認証サービス上で管理されるユーザー情報のデータ構造例。 （Ｂ）認証サービス上で管理されるユーザー認証情報のデータ構造例。
【図７】認証サービスのログ収集のフローチャート。
【図８】（Ａ）認証ＡＰＩサービスが出力するログ情報例。 （Ｂ）認証・認可サービスが出力するログ情報例。 （Ｃ）認証・認可サービスが出力したログを認証サービスのログに変換したログ情報例。
【図９】認証サービスのログをマルチテナントに対応させて収集する際のフローチャート。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【実施例１】
【００１５】
［システム構成］
図１は、本発明の実施例のシステム構成を示すブロック図である。
【００１６】
図中１０は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１０）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。図中１１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１）である。また図中１２はファイアーウォールである。
【００１７】
図中１３はクライアント１７からの要求を受け、認証サービスを利用してウェブサービスを提供するサービス提供サーバー１３である。図中１４は、認証サービスを利用するサービスからの要求を受け、認証・認可サーバーへと処理を行うＡＰＩ（Ａｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する認証ＡＰＩサーバー１４であり、ＡＰＩを利用した呼び出しを受けることで所定の機能を動作させる。図中１５は認証ＡＰＩサービスや認証サービスを提供するサービスからの要求を受け、ユーザー認証や認証情報管理、ユーザーの認可を行う認証・認可サーバー１５である。
【００１８】
図中１６は認証・認可サービス、認証ＡＰＩサービス、認証サービスを利用するサービスが連携している認証サービスである。なお、認証サービスを利用するサービスは不図示の他のサービスであってもよく、その場合、認証サービスは認証・認可サービスと認証ＡＰＩサービスとが連携するサービスとなる。なお、認証サービスがサーバーシステムに相当し、サーバーシステムは１台から構成されるシステムであっても、複数台から構成されるシステムであっても良い。認証サービス１６を提供するサーバーシステムの運用方法について特に制限はない。よって、認証・認可サーバーを認証サービス部と称し、認証ＡＰＩサーバーを認証ＡＰＩサービス部と称し、サービス提供サーバーをサービス提供サービス部、またはウェブサービス部と称する。
【００１９】
図中１７はＬＡＮ１１およびＷＡＮ１０を介して各サーバーに対してＷｅｂリクエストを発行するクライアント端末１７であり、より具体的にはＷＷＷを参照可能なＷｅｂブラウザを備えたクライアント端末である。
【００２０】
［ハードウェア構成］
図２は、図１中の認証・認可サーバー１３、認証ＡＰＩサーバー１４、サービス提供サーバー１５、あるいはクライアント端末１７のハードウェア構成を示すブロック図である。図２に示されるハードウェア構成図は一般的な情報処理装置及び出力デバイスのハードウェア構成図に相当するものとし、本実施形態の各情報端末、サーバーは一般的な情報処理装置のハードウェア構成を適用できる。
【００２１】
図２において、ＣＰＵ２０は、ＲＯＭ２２に記憶された、或いはＨＤＤ２３からＲＡＭ２１にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２１は、ＣＰＵ２０の主メモリ、ワークエリア等として機能する。入力装置２４は、不図示のキーボードや不図示のポインティングデバイスからのキー入力を制御する。出力装置２５は、不図示の各種ディスプレイの表示を制御する。ＨＤＤ２３は、各種データを記憶する外部メモリ、例えばハードディスクやフラッシュメモリなどの永続記憶装置である。ネットワークインターフェース２６はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００２２】
［ソフトウェア構成］
図３は、本発明の実施形態に係るサービス提供サーバー１３上で動作する、認証サービス利用サービス３０のソフトウェアモジュールの構成図である。
【００２３】
Ｗｅｂアプリケーション３０１はＷｅｂからのリクエストを受け付けるＷｅｂインタフェースを備えており、クライアント１７が備えるＷｅｂブラウザからのリクエストに対して不図示の画面を生成して応答する。Ｗｅｂアプリケーション３０１は認証サービスへの処理要求を受けると、認証ＡＰＩＩ／Ｆ３０２を利用して、認証ＡＰＩサービス４０へと処理要求を行う。
【００２４】
エージェント部３０３は、Ｗｅｂアプリケーション３０１に処理要求が来た際に、その要求をしたユーザーの認証状態を確認する。要求者が認証されていなかった場合や認証の有効期限が切れていた場合、Ｗｅｂアプリケーション３０１に認証要求画面を作成、表示させて、認証を要求する。ここで、本発明では認証方式として、ユーザーを特定するユーザーＩＤおよびパスワードを認証情報として登録しておき、認証リクエストで取得した情報とのマッチングを行う方式として説明する。ただし、この認証方式に制限するものではなく、電子証明書を確認する方式など、他の認証方式でも実現可能である。エージェント部３０３はユーザーＩＤおよびパスワードを取得すると、認証・認可サービス５０に対して認証を要求する。認証に成功した場合、認証状態を管理する認証トークンを返す。
【００２５】
図４は、認証ＡＰＩサーバー上で動作する、認証ＡＰＩサービス４０のソフトウェアモジュールの構成図である。
【００２６】
認証ＡＰＩＩ／Ｆ４０１は、他のサービスから認証ＡＰＩへの要求を受け取る。他のサービスとは、例えば、サービス提供サーバー１３が提供する認証サービス利用サービス３０からの要求である。ＡＰＩ処理部４０２は認証ＡＰＩＩ／Ｆ４０１によって受け取った要求に基づいて処理を行い、必要に応じて通信部４０３を介して認証・認可サービス５０が管理する情報を取得し、その要求に応える。また、ＡＰＩ処理部４０２で行った処理の内容はリアルタイムでログに出力され、認証ＡＰＩサービス４０のログとして認証ＡＰＩサーバー１４内の認証ＡＰＩサービスログフォルダに保存される。即ち、ＡＰＩ処理部４０２での処理が完了した時点でログが出力される。認証ＡＰＩサービスは、第１の間隔（ＡＰＩ処理部４０２での処理が完了した時点で出力されるので、第１の間隔とは処理が完了する間隔のことを指す）でログを主力する
ログ処理部４０４は、認証サービスとして連携する全てのサービスの中で、最も出力間隔が長いサービスのログが出力された時点で起動する。ログ処理部４０４は起動すると、上記認証ＡＰＩサービス４０のログを認証サービス１６の一時ログとして認証ＡＰＩサーバー１４内の認証サービス一時ログフォルダに移動する。また同時に通信部４０３を介して認証・認可サービス５０へとログ取得要求を行い、取得したログを認証サービス１６の一時ログとして認証サービス一時ログフォルダに保存する。その後、認証サービス一時ログフォルダ内のログを確認し、ログ出力時間で最も古い時刻までのログを抽出し、その時刻までのログを認証サービス１６のログとして認証サービスログフォルダに移動する。例えば、１時間ごとにログを出力するサービスと４５分ごとにログを出力するサービスが連携していた場合には、１時間毎にログを収集する。そして１時間ごとに出力するサービスが１３；００まで、４５分ごとに出力するサービスが１２：４５までのログが出力されていた場合、１２：４５までのログをサービス全体のログとして保存する。換言すれば、あるサービス部がログを出力した時点から最も短い間隔が経過するまでに出力されたログを認証ログとして出力する。
【００２７】
なお、本処理部の機能は認証ＡＰＩサーバー以外の不図示のログ収集サーバーにあってもよい。その場合、ログ処理部４０４は外部サービスからの要求を受け、認証ＡＰＩサービスのログを取得し、外部サービスへと送信する処理を行う。
【００２８】
図５は、認証・認可サービス上で動作する、認証・認可サービス５０のソフトウェアモジュールの構成図である。
【００２９】
設定部５０１は、通信Ｉ／Ｆ５０３を介してユーザー情報の設定要求を受け、認証情報記憶部５０５の情報の設定を行う。
認証・認可部５０２は、通信Ｉ／Ｆ５０３やエージェント通信Ｉ／Ｆ５０４を介して認証・認可要求を受け、認証情報記憶部５０５の情報を利用して認証および認可を行う。認証・認可部５０２は認証に成功した場合、認証トークンを発行し、認証情報（ユーザーＩＤ・パスワード）と関連付けて認証情報記憶部５０５に保存し管理する。また、認証・認可部５０２での処理内容はログとして１時間毎に出力され、認証・認可サービス５０のログとして認証・認可サーバー１５内の認証・認可サービスログフォルダに保存される。認証・認可サービス５０がログを出力する間隔が第２の間隔に相当し、第２の間隔は第１の間隔よりも長いものとする。ログ処理部５０６は、通信Ｉ／Ｆ５０３を介してログ取得要求を受け付け、認証・認可サービスログフォルダ内のログを送信する。なお、認証トークンを有する装置が、ウェブサービス部が提供するウェブサービスを利用する際、認証情報を入力することなく利用可能となる。認証トークンは、利用の制限が設けられた認可トークンであっても良い。
【００３０】
［データ構造］
図６は認証情報記憶部５０５にて管理されているユーザー認証情報の例である。
【００３１】
図６（Ａ）は、ユーザー認証情報のデータ構造の一例であり、ユーザーを特定するためのユーザーＩＤ６０１とパスワード６０２、およびユーザー属性が管理されている。ユーザー属性は、ユーザーが所属するテナント情報を示すテナントＩＤ６０３とユーザーの権限情報６０４、その他のユーザー属性情報６０５からなる。
図６（Ｂ）は、ユーザーの認証状態を管理する認証トークン情報の一例であり、ユーザーを特定するユーザーＩＤ６１１および、ユーザーが認証されたことを示すトークン６１２からなる。
【００３２】
［フローチャート］
以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。
【００３３】
図７は、認証ＡＰＩサービス４０および認証・認可サービス５０が連携している認証サービス１６において、認証サービス１６のログとして認証ＡＰＩサービス４０と認証・認可サービス５０のログを集める際の処理フローである。
【００３４】
以下のフローにおいて、認証ＡＰＩサービス４０はリアルタイムにログを出力し、認証・認可サービス５０は１時間ごとにログを出力するものとする。そのため、認証ＡＰＩサービス４０のログ処理部４０４は１時間ごとに起動するものとする。
【００３５】
ログ処理部４０４が起動すると、ステップＳ７０１、Ｓ７０２において認証ＡＰＩサービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップＳ７０３にて対応するログを認証サービス一時ログフォルダに移動する。
また、ログ処理部４０４は起動時にステップＳ７０４にて、連携している認証・認可サービスのログを要求する。認証・認可サービス５０のログ処理部５０６は、ステップＳ７０５にて認証ＡＰＩサービスからのログ要求を受け付けると、ステップＳ７０６で認証・認可サービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップＳ７０７にて対応するログをログ送信用のフォルダに移動する。その後ステップＳ７０８にて、ログ送信用フォルダ内のログを認証ＡＰＩサービスへと送信する。
【００３６】
認証ＡＰＩサービスのログ処理部は、ステップＳ７０９で認証・認可サービスのログを受信すると、ステップＳ７１０にて受信したログを認証サービス一時ログフォルダに移動する。
【００３７】
全てのサービスのログを取得すると、ステップＳ７１１にて、ログ出力時間が最も古いログを調べ、その時刻までに出力されたログを抽出する。なお、過去に抽出されずに残っていたログも抽出対象とする。その後ステップＳ７１２にて、抽出されたログを認証サービス１６のログとして、認証サービスログフォルダへと移動する。認証サービスログフォルダへ移動する際、第２の間隔毎に移動することとするが、第２の間隔よりも長い間隔で移動させても良い。なぜなら、ある期間内に出力された、認証ＡＰＩサービス部により出力されたログと、認証サービス部により出力されたログとが漏れなく提供されるからである。
【００３８】
以上のフローにより、異なるタイミングでログを出力するサービスが連携している場合に、全てのサービスが出力したある時間までのログを、欠けることなくまとめることが出来る。
【実施例２】
【００３９】
次に、本発明を実施するための第２の形態について図面を用いて説明する。
【００４０】
第１の実施例においては、連携しているサービスが異なる間隔でログを出力する場合に、ある時間までに全てのサービスが出力するログを不足なく集めることができた。本実施例では、第１の実施例において、連携しているサービスの中にマルチテナントに対応していないサービスが存在した場合にログを収集する方法を説明する。なお、本実施例においては、第１の実施例と同一部分に関する説明は省略し、その差異についてのみ説明する。
【００４１】
［データ構造］
図８は認証ＡＰＩサービス、認証・認可サービスにおいて出力されるログ情報の例と、第二の実施形態に基づいて変換されたログ情報の例を示す。
【００４２】
図８（Ａ）は、マルチテナントに対応している認証ＡＰＩサービスが出力するログ情報である。処理が実行された日時と実行者の情報および処理内容からなる。実行者の情報には、実行者を表すユーザーＩＤと、実行者のテナント情報を表すテナントＩＤが含まれて記載されている。
一方、図８（Ｂ）は、マルチテナントに対応していない認証・認可サービスが出力するログ情報である。図８（Ａ）と同様に処理が実行された日時と実行者情報、処理内容からなるが、マルチテナントに対応していないため、テナント情報が記載されたログは出力されない。
図８（Ｃ）は、図８（Ｂ）に示した認証・認可サービスが出力するログ情報を、第二の実施例に基づいて変換したログ情報である。図８（Ｂ）のログ情報にユーザーのテナント情報を表すテナントＩＤが追加されたログとなる。
【００４３】
［フローチャート］
以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。
【００４４】
図９は、認証ＡＰＩサービスおよび認証・認可サービスが連携している認証サービスにおいて、ログを集める際の処理フローである。
【００４５】
以下のフローにおいて、認証ＡＰＩサービス４０はマルチテナントに対応しており、認証・認可サービス５０はマルチテナントに対応していないサービスとする。また、認証・認可サービス５０上のユーザー情報には、テナント情報がユーザーの属性情報の一つとして管理されており、認証ＡＰＩを用いて取得できるものとする。
【００４６】
ステップＳ７０１からステップＳ７１０までは、図７と同じ処理である。
【００４７】
認証ＡＰＩサービスのログ処理部は、ステップＳ７１０で認証・認可サービスのログを受け取ると、ステップＳ９０１でそのログを１件読み込む。ログ処理部はステップＳ９０２にて、ログに含まれるユーザー情報を利用してユーザーのテナントＩＤ情報取得要求を行う。
【００４８】
認証・認可サービスの設定部５０１は、ステップＳ９０３にてテナントＩＤ情報取得要求を受けると、ステップＳ９０４でユーザー属性からテナント情報を表すテナントＩＤを取得する。その後ステップＳ９０５にて取得したテナント情報を認証ＡＰＩサービスへと返す。
【００４９】
認証ＡＰＩサービスはステップＳ９０６にてテナント情報を受け取ると、ステップＳ９０７にてログにテナント情報を追記し、ログ情報が補完され、補完情報が追加済みのログとしてログ情報を保存する。その後、全てのログにテナント情報を追加するまで、ステップＳ９０１からステップＳ９０７を繰り返す。こうして全てのログにテナント情報を追加した後で、ステップＳ７１１およびＳ７１２を行い、認証サービス１６のログを取得する。
【００５０】
以上のフローにより、マルチテナントに対応していないサービスが出力するログにテナント情報を追加して、マルチテナントに対応したログとすることができる。
【符号の説明】
【００５１】
１０ ＷＡＮ
１１ ＬＡＮ
１２ ファイアーウォール
１３ サービス提供サーバー
１４ 認証ＡＰＩサーバー
１５ 認証・認可サーバー
１６ 認証サービス
１７ クライアント端末
３０ 認証サービス利用サービス
４０ 認証ＡＰＩサービス
５０ 認証・認可サービス
【特許請求の範囲】
【請求項１】
ウェブサービスを提供するウェブサービス部と、
前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、
前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証ＡＰＩサービス部とから構成され、
前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、
前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、
前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、
前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とするサーバーシステム。
【請求項２】
前記認証サービスのログを出力する際、前記認証サービス部がログを出力した時点から前記第１の間隔が経過するまでの間に、前記一時ログフォルダへ保存されたログを前記認証サービスのログとして前記ログフォルダへ出力することを特徴とする請求項１に記載のサーバーシステム。
【請求項３】
前記認証ＡＰＩサービス部が出力するログにはテナント情報が記載されており、一方、前記認証サービス部が出力するログにはテナント情報が記載されていない場合であって、
前記認証サービスが出力したログに記載されているユーザー情報を基に、該ユーザー情報に関連するテナント情報を前記認証サービス部から取得し、前記認証サービスが出力したログに追記することを特徴とする請求項１または２に記載のサーバーシステム。
【請求項４】
ウェブサービス部は、ウェブサービスを提供し、
認証サービス部は、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理し、
認証ＡＰＩサービス部は、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応え、
前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、
前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、
前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、
前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力するようにサーバーシステムを制御する制御方法。
【請求項５】
請求項４に記載の制御方法をサーバーシステムに実行させるためのプログラム。
【請求項１】
ウェブサービスを提供するウェブサービス部と、
前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、
前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証ＡＰＩサービス部とから構成され、
前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、
前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、
前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、
前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とするサーバーシステム。
【請求項２】
前記認証サービスのログを出力する際、前記認証サービス部がログを出力した時点から前記第１の間隔が経過するまでの間に、前記一時ログフォルダへ保存されたログを前記認証サービスのログとして前記ログフォルダへ出力することを特徴とする請求項１に記載のサーバーシステム。
【請求項３】
前記認証ＡＰＩサービス部が出力するログにはテナント情報が記載されており、一方、前記認証サービス部が出力するログにはテナント情報が記載されていない場合であって、
前記認証サービスが出力したログに記載されているユーザー情報を基に、該ユーザー情報に関連するテナント情報を前記認証サービス部から取得し、前記認証サービスが出力したログに追記することを特徴とする請求項１または２に記載のサーバーシステム。
【請求項４】
ウェブサービス部は、ウェブサービスを提供し、
認証サービス部は、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理し、
認証ＡＰＩサービス部は、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応え、
前記認証サービス部と、前記認証ＡＰＩサービス部は連携して認証サービスを提供し、
前記認証ＡＰＩサービス部は、要求を受け取り処理したことを示すログを第１の間隔で出力し、
前記認証サービス部は、要求を受け取り処理したことを示すログを前記第１の間隔よりも間隔が長い第２の間隔で出力し、
前記認証ＡＰＩサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第２の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力するようにサーバーシステムを制御する制御方法。
【請求項５】
請求項４に記載の制御方法をサーバーシステムに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−１１９５７（Ｐ２０１３−１１９５７Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１１−１４２９９７（Ｐ２０１１−１４２９９７）
【出願日】平成２３年６月２８日（２０１１．６．２８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２３年６月２８日（２０１１．６．２８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]