JP2007172588A - 認証チケット処理装置 - Google Patents

Abstract

【課題】自己記述型チケットの持つパフォーマンスの欠点を解決しユーザ情報の取得を高速化する。
【解決手段】クライアントがサーバからサービスの提供を受けるのに際し、クライアントからの認証要求に応じ認証チケットを作成してクライアントに提供するとともに、クライアントからのサービス要求に伴う認証チケットにつきサーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理システムにおいて、ユーザ情報を管理するユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を保持する、ユーザ管理ＤＢよりアクセス速度の速いデータ一時保持部を備え、ユーザ情報を取り込む必要がある場合、データ一時保持部での目的とするユーザ情報の有無を調べ、データ一時保持部に保持されているユーザ情報については、データ一時保持部からユーザ情報を取得する。
【選択図】図４

Description

本発明は、ユーザ情報の取得を高速化することのできる認証チケット処理装置に関する。

ネットワーク上のサーバから迅速かつ安全なサービス提供を行うため、認証チケットが用いられることがある。

認証チケットには用途に応じて各種の仕様が存在するが、そのうちの一つとして、デコード時点でのユーザ情報を返す仕様の「自己記述型チケット（SelfContainedチケット）」と呼ばれる認証チケットがある。

図１は従来における認証要求から認証チケット取得までの処理の流れを示す図であり、サービスサーバ２からサービス提供を受けるのに先立ち、クライアント１からユーザ認証装置（ＵＡＵＤ：User Authentication by User Directory）３に認証要求を行うと（ステップＳ１）、ユーザ認証装置３はユーザ管理ＤＢ４にユーザ情報の確認を行い（ステップＳ２）、確認がとれるとユーザ管理ＤＢ４からユーザＩＤ情報のみを取得する（ステップＳ３）。そして、ユーザＩＤ情報に基づいて認証チケットを構成（作成）し（ステップＳ４）、クライアント１に認証チケットを提供する（ステップＳ５）。

図２は従来におけるサービス要求からサービス開始までの処理の流れを示す図であり、クライアント１がサービスサーバ２に対して認証チケットを伴ったサービス要求を行うと（ステップＳ１１）、サービスサーバ２はユーザ認証装置３に対して認証チケットのデコード要求を行う（ステップＳ１２）。ユーザ認証装置３はユーザ管理ＤＢ４からユーザ情報（ユーザＩＤ情報以外の情報を含む）を取得し（ステップＳ１３、Ｓ１４）、サービスサーバ２にユーザ情報を提供し（ステップＳ１５）、サービスサーバ２は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する（ステップＳ１６）。

一方、特許文献１には、蓄積文書に対する認証機能を共有することができ、ネットワークおよび融合機のリソースを浪費することなく蓄積文書の供給が可能な画像形成装置、蓄積文書管理方法および蓄積文書処理システムが開示されている。
特開２００４−１３５２９１号公報

ところで、図２において、サービスサーバ２は同じ認証チケットであっても、そのような認証チケットを伴った新たなサービス要求を受け取る度にユーザ認証装置３に対してデコード要求を行い、ユーザ認証装置３はユーザ管理ＤＢ４からユーザ情報の取得を行う。これは、自己記述型チケットでは、認証チケットを長期間保有している場合に、そのユーザの登録状況が変化してしまい、認証時のユーザ情報とデコード時のそのユーザの持つ実際のユーザ情報とが異なってしまうことが生じる可能性があるためである。例えば、ワークフローなど、文書の配信、印刷等をする場合、開始時に何らかの理由で待機状態になることがある。待機状態からその機能が可能な状態になる時刻は、前もっては判らない。そのため、再開時に利用する認証チケットは長期間利用可能でなければならない。しかし、組織異動や休職・退職などにより、認証時点でのそのユーザの情報が、機能が利用可能となった時点で異なってしまうことは容易に考えられる。そのため、認証チケットからユーザ情報をデコードする際にユーザ情報をユーザ管理ＤＢ４から取得するようにしていた。

従来のシステムはこのような仕組となっていたため、サービスサーバ２における複数のサービスが同一の認証チケットを同時に利用する場合、ユーザ認証装置３側には、短い時間間隔（例：数秒間隔）でデコード要求が発生することが起こり、その度に同一ユーザ情報に関するユーザ管理ＤＢ４へのデータベース参照が発生してしまうという問題があった。図３は従来において認証チケットデコード要求が頻発した様子を示す図であり、サービスサーバ２からユーザ認証装置３へのデコード要求が短い時間間隔で連続発生し（ステップＳ２２）、これに応じてユーザ認証装置３からユーザ管理ＤＢ４に対するユーザ情報の取得が連続発生（ステップＳ２３）している様子を示している。

このように、同一の自己記述型チケットに対し短い時間間隔でデコードが要求された場合、従来のシステムでは、その度に同一ユーザ情報に関するユーザ管理ＤＢ４へのデータベース参照が発生してしまい、パフォーマンスが低下してしまうという問題があった。

このような問題点は自己記述型チケットの仕様であるが故に止むを得ないとも考えられるが、このような仕様が想定するユーザ情報の変更は頻繁に起こるものではなく、パフォーマンス低下とトレードオフの関係にあると考えるのはバランスを欠いている。すなわち、文書管理システム等を利用するユーザのユーザ情報が頻繁に変更されることはなく、変更されるとしても人事異動など組織変更があった場合が主であるので、年に数回、多くても月に数回と考えるのが自然であり、その際の不都合を回避するためにデコード要求の度にデータベース参照を行うのは行き過ぎである。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することのできる認証チケット処理装置を提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、ユーザ情報を管理するユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理ＤＢよりアクセス速度の速いデータ一時保持部を備え、上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得する認証チケット処理装置を要旨としている。

また、請求項２に記載されるように、請求項１に記載の認証チケット処理装置において、上記データ一時保持部が保持するデータを管理する管理部を備え、上記データ一時保持部はユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除するようにすることができる。

また、請求項３に記載されるように、請求項１または２のいずれか一項に記載の認証チケット処理装置において、上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理ＤＢからユーザ情報を取得するようにすることができる。

また、請求項４に記載されるように、請求項２に記載の認証チケット処理装置において、上記指定期間は、上記データ一時保持部からのデータの取得により延長されるようにすることができる。

また、請求項５に記載されるように、請求項４に記載の認証チケット処理装置において、上記指定期間の延長は、上記ユーザ管理ＤＢからユーザ情報を取得してから一定期間に限られるようにすることができる。

また、請求項６〜１０に記載されるように、認証チケット管理方法として構成することができる。

本発明の認証チケット処理装置にあっては、ユーザ管理ＤＢから取得したユーザ情報をユーザ管理ＤＢよりアクセス速度の速いデータ一時保持部に保持し、ユーザ情報を取り込む必要がある場合にデータ一時保持部からユーザ情報を取得するようにしたので、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することができる。

以下、本発明の好適な実施形態につき説明する。

＜第１の実施形態＞
図４は本発明の第１の実施形態にかかるシステムの構成例を示す図である。図４において、システムは、サービスの提供を受けるユーザが使用するＰＣ（Personal Computer）、携帯電話、ＰＤＡ（Personal Digital Assistant）等のクライアント１と、サービスを提供する複数のサービスサーバ２と、認証チケットの作成およびデコードを行うユーザ認証装置３と、ユーザ情報を管理するユーザ管理ＤＢ４とを備えている。また、ユーザ認証装置３は、認証チケットの作成およびデコードの主たる処理を行うユーザ認証制御部３１と、ユーザ認証制御部３１の制御のもとユーザ情報を期限付きで保持するチケットプール（ユーザ情報一時保持部）３２と、チケットプール３２の生存期限を監視して適宜に削除を行う生存期限監視部３３とを備えている。

図５は第１の実施形態におけるチケットプール３２の構造を示す図であり、自己記述型チケットが格納されるキー３２ａと、キー３２ａに関連付けられて格納される生存期限３２ｂおよびユーザ情報３２ｃとを有している。ここで、生存期限３２ｂは、自己記述型チケットに含まれる有効期限とは独立したものであり、その認証チケットが生成された日時に指定期間を加えた値となる。なお、指定期間は、短い時間間隔でデコード要求が頻発する場合に対応できる範囲内で、デコード時点でのユーザ情報を返すという自己記述型チケットの仕様から大きく逸脱しないよう、十分に短い値（例えば３０秒）とする。

図６は第１の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。図６において、サービスサーバ２からサービス提供を受けるのに先立ち、クライアント１からユーザ認証装置３のユーザ認証制御部３１に認証要求を行うと（ステップＳ１０１）、ユーザ認証制御部３１はユーザ管理ＤＢ４にユーザ情報の確認を行い（ステップＳ１０２）、確認がとれるとユーザ管理ＤＢ４からユーザ情報を取得する（ステップＳ１０３）。このユーザ情報は、ユーザＩＤ情報だけでなく、デコード時に必要な情報すべてを含む。

ユーザ認証制御部３１は取得したユーザ情報のうちユーザＩＤ情報に基づいて認証チケットを構成（作成）するとともに（ステップＳ１０４）、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール３２に格納し（ステップＳ１０５）、クライアント１に認証チケットを提供する（ステップＳ１０６）。

図７は第１の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図７において、クライアント１がサービスサーバ２に対して認証チケットを伴ったサービス要求を行うと（ステップＳ１１１）、サービスサーバ２はユーザ認証装置３のユーザ認証制御部３１に対して認証チケットのデコード要求を行う（ステップＳ１１２）。

ユーザ認証制御部３１は、ユーザ管理ＤＢ４にはアクセスせず、チケットプール３２からユーザ情報の取得を行い（ステップＳ１１３、Ｓ１１４）、サービスサーバ２にユーザ情報を提供する（ステップＳ１１５）。

サービスサーバ２は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する（ステップＳ１１６）。

一方、生存期限監視部３３は常時もしくは定期的にチケットプール３２に保持されたユーザ情報の生存期限３２ｂと現在時刻とを比較し、生存期限を過ぎたユーザ情報を削除しあるいは無効にする。図８は第１の実施形態におけるチケットプール３２のユーザ情報等の削除の例を示す図であり、認証チケットが生成され、何度か参照がされた後、生成から指定期間経過の生存期限満了により、認証チケットは削除される。

図９は目的の認証チケットが削除されている場合の第１の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図９において、クライアント１がサービスサーバ２に対して認証チケットを伴ったサービス要求を行うと（ステップＳ１２１）、サービスサーバ２はユーザ認証装置３のユーザ認証制御部３１に対して認証チケットのデコード要求を行う（ステップＳ１２２）。

ユーザ認証制御部３１は、チケットプール３２からユーザ情報の取得を試みるが（ステップＳ１２３、Ｓ１２４）、目的のユーザ情報がないため、ユーザ管理ＤＢ４からユーザ情報を取得する（ステップＳ１２５、Ｓ１２６）。

そして、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール３２に格納し（ステップＳ１２７）、サービスサーバ２にユーザ情報を提供する（ステップＳ１２８）。

サービスサーバ２は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する（ステップＳ１２９）。

図１０は第１の実施形態における全体の処理を示すフローチャートであり、Ｓ２０１〜Ｓ２０９が認証要求から認証チケット取得までの処理、Ｓ２１０〜Ｓ２３１がサービス要求からサービス開始までの処理、Ｓ２４１〜Ｓ２４４がチケットプール３２のユーザ情報等の削除の処理である。

このように、認証チケットのデコード要求に対しては、チケットプール３２から優先的にユーザ情報を取得するため、デコード要求が短時間に頻発するようなことがあってもパフォーマンスの低下を防止することができる。

また、ユーザ情報を情報取得の時刻と併せて保持し、指定期間経過後に削除することから、その期間を適当に設定することにより、一時的に集中して発生するデコード要求に対しパフォーマンス向上の効果を保ったまま、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を鮮度を保った状態の十分な精度で返すことが可能になる。

＜第２の実施形態＞
図１１は本発明の第２の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図であり、チケットプール３２に保持したユーザ情報の生存期限を更新するようにしたものである。

すなわち、上述した第１の実施形態においては、一連の操作の都合上連続してデコード要求しているかどうかに関わらず、指定期間経過後になるとチケットプール３２からユーザ情報が破棄され、その後のデコード要求に対してはユーザ管理ＤＢ４からユーザ情報を取得することになる。そのため、一連のデコードの前半と後半とでデコードされる情報が異なる可能性がある。複数のサービスから連続してデコードの要求があった場合、これら一連のサービスは関連したアプリケーションを構成することが多く、デコード結果も同一情報であることが望ましい。そこで、この第２の実施形態ではチケットプール３２からユーザ情報を取得した際、その度に生存期限情報を初期化するようにしている。

図１１において、クライアント１がサービスサーバ２に対して認証チケットを伴ったサービス要求を行うと（ステップＳ１３１）、サービスサーバ２はユーザ認証装置３のユーザ認証制御部３１に対して認証チケットのデコード要求を行う（ステップＳ１３２）。ここでは複数のサービスから連続してデコード要求が発生したものとする。

ユーザ認証制御部３１は、チケットプール３２からユーザ情報の取得を行うが（ステップＳ１３３、Ｓ１３５）、ユーザ情報の取得を行う度に生存期限の更新を行う（ステップＳ１３４）。

ユーザ認証制御部３１はサービスサーバ２にユーザ情報を提供し（ステップＳ１３６）、サービスサーバ２は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する（ステップＳ１３７）。

図１２は第２の実施形態におけるチケットプール３２のユーザ情報等の削除の例を示す図であり、第１の実施形態では、（ａ）に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除されるが、この第２の実施形態では、（ｂ）に示すように参照される度に指定期間が開始し、最後の参照から指定時間後に削除されることになる。

このように、チケットプール３２からのデータの取得により生存期限が延長されることにより、一連のデコード要求の間はチケットプール３２のユーザ情報が破棄されることはなくなり、一連のデコードの前半と後半とでデコードされる情報が異なるという事態を避けることができる。

＜第３の実施形態＞
図１３は本発明の第３の実施形態におけるチケットプールの構造を示す図であり、生存期限の延長の上限値を設定可能にしたものである。

すなわち、上述した第２の実施形態においては、デコード要求が混雑している場合など、常に短い時間間隔で要求が発生してしまうとチケットプール３２からユーザ情報が破棄されることが阻害され、結局その場合、ユーザ管理ＤＢ４からユーザ情報を取得することがなくなってしまう。すなわち、本来、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱してしまうことになる。そこで、この第３の実施形態ではチケットプール３２で管理されるユーザ情報について、その生存期限に加え上限値も同時に管理するようにしている。

図１３において、自己記述型チケットが格納されるキー３２ａと、キー３２ａに関連付けられて格納される生存期限３２ｂおよびユーザ情報３２ｃとに加え、生存期限の延長可能な上限値３２ｄを設けるようにしている。なお、上限値３２ｄは、ユーザ管理ＤＢ４からユーザ情報を取得した時点で初期化する。

図１４は本発明の第３の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図１４において、クライアント１がサービスサーバ２に対して認証チケットを伴ったサービス要求を行うと（ステップＳ１４１）、サービスサーバ２はユーザ認証装置３のユーザ認証制御部３１に対して認証チケットのデコード要求を行う（ステップＳ１４２）。ここでは複数のサービスから連続してデコード要求が発生したものとする。

ユーザ認証制御部３１は、チケットプール３２からユーザ情報の取得を行うが（ステップＳ１４３、Ｓ１４５）、ユーザ情報の取得を行う度に生存期限の更新を行う（ステップＳ１４４）。ただし、生存期限の更新は上限値３２ｄを限度とする。

ユーザ認証制御部３１はサービスサーバ２にユーザ情報を提供し（ステップＳ１４６）、サービスサーバ２は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する（ステップＳ１４７）。

図１５は第３の実施形態におけるチケットプール３２のユーザ情報等の削除の例を示す図であり、第１の実施形態では、（ａ）に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除され、第２の実施形態では、（ｂ）に示すように参照が連続する限り削除されないが、この第３の実施形態では、（ｃ）に示すように上限値を超えない範囲で最後の参照から一定時間後に削除され、その後のデコードに対しては新しいユーザ情報が参照される。

このように、生存期限の延長の上限値を設定可能にしたため、デコード要求が混雑している場合でも、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱することを防止することが可能になる。

＜サービスサーバ連携の例＞
上述したサービスサーバ２は互いに独立して存在しており、サービスサーバ２を任意に追加、削除することが可能である。また、アプリケーションを実現させるためには、複数のサービスサーバ２を実行し連携させる。

アプリケーション毎にどのサービスサーバ２が連携するかによって、様々な制御が考えられ、例えば、次の３パターンがある。
（１）クライアントが規定する場合。
（２）アプリケーションを規定する第３のサービスサーバが規定する場合。
（３）認証チケット自体に起動サービスの規定がある場合。

図１６はクライアントが規定する場合のサービスサーバの連携の例を示す図である。図１６において、クライアント１が文書印刷する際、クライアント１の制御のもと、リポジトリサービス２１と印刷サービス２２を起動している。なお、リポジトリサービス２１、印刷サービス２２のそれぞれは、自らのサービスのアクセス権を判断するために、ユーザ認証装置３によりそれぞれ認証チケットをデコードする。ユーザ認証装置３は、同一ユーザに対する認証チケットを短い期間内で複数回デコードすることになる。

図１７はこの場合の処理例を示すシーケンス図であり、Ｓ３０１〜Ｓ３０７が認証チケット取得の処理、Ｓ３０８がクライアント１による文書印刷の指示、Ｓ３０９〜Ｓ３１５がリポジトリサービス２１による処理、Ｓ３１６〜Ｓ３２１が印刷サービス２２による処理、Ｓ３２２、Ｓ３２３がクライアント１によるサービス受付待ちの処理である。なお、Ｓ３０９とＳ３１６でリポジトリサービス２１と印刷サービス２２に同時並行に認証チケットを渡しているが、リポジトリサービス２１が対象文書を取得した後に印刷サービス２２に認証チケットを渡すようにしてもよい。

図１８はアプリケーションを規定する第３のサービスサーバが規定する場合のサービスサーバの連携の例を示す図である。図１８において、クライアント１が文書配信する際、配信アプリケーションサービス２３の制御のもと、リポジトリサービス２１と配信サービス２４を起動し、それぞれのサービスが認証チケットをデコードする。なお、配信アプリケーションサービス２３は、受け取った認証チケットをデコードしても良く、その際はデコード結果により、配下のサービスサーバを制限することも可能になる。配信サービス２４は、配信に失敗するとインターバル期間後、再度配信を開始する。この動作も先のデコード結果で切り替えることが可能である。配信の再開時、認証チケットのデコードで返されるユーザ情報は、その時点のユーザ情報になる。

図１９はこの場合の処理例を示すシーケンス図であり、Ｓ４０１〜Ｓ４０７が認証チケット取得の処理、Ｓ４０８がクライアント１による文書配信の指示、Ｓ４０９〜Ｓ４２８が配信アプリケーションサービス２３の制御によるリポジトリサービス２１と配信サービス２４の処理、Ｓ４２９〜Ｓ４３９が配信失敗の場合の再配信処理である。なお、Ｓ４１０とＳ４１７でリポジトリサービス２１と印刷サービス２２に同時並行に認証チケットを渡しているが、リポジトリサービス２１が対象文書を取得した後に印刷サービス２２に認証チケットを渡すようにしてもよい。

図２０は認証チケット自体に起動サービスの規定がある場合のサービスサーバの連携の例を示す図である。図２０においては、サービスサーバ２とユーザ認証装置３がＭＦＰ（Multi Function Printer）機器の内部にある場合を例としており、例えば、コピーする際にはコピーアプリサービス２５の実現機能としてスキャンフィルタ２６、印刷フィルタ２７、画像処理フィルタ２８が起動する。クライアント１のユーザ毎に利用可能なフィルタの種類が制限されているとき、認証チケットにその情報（起動可能なフィルタの種類）が含まれることで、起動可能なサービスが決定される。

図２１はこの場合の処理例を示すシーケンス図であり、Ｓ５０１〜Ｓ５０７の認証チケット取得の処理では、ユーザにより利用可能なサービスの種類が規定された認証チケットが発行される。また、Ｓ５０８はクライアント１による文書配信の指示、Ｓ５０９〜Ｓ５３５はコピーアプリサービス２５の制御によるスキャンフィルタ２６、印刷フィルタ２７、画像処理フィルタ２８の処理、Ｓ５３６はクライアント１による終了待ちの処理である。

＜総括＞
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

従来における認証要求から認証チケット取得までの処理の流れを示す図である。 従来におけるサービス要求からサービス開始までの処理の流れを示す図である。 従来において認証チケットデコード要求が頻発した様子を示す図である。 本発明の第１の実施形態にかかるシステムの構成例を示す図である。 第１の実施形態におけるチケットプールの構造を示す図である。 第１の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。 第１の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図（その１）である。 第１の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。 第１の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図（その２）である。 第１の実施形態における全体の処理を示すフローチャートである。 本発明の第２の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。 第２の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。 本発明の第３の実施形態におけるチケットプールの構造を示す図である。 本発明の第３の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。 第３の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。 サービスサーバの連携の例を示す図（その１）である。 サービスサーバの連携における処理例を示すシーケンス図（その１）である。 サービスサーバの連携の例を示す図（その２）である。 サービスサーバの連携における処理例を示すシーケンス図（その２）である。 サービスサーバの連携の例を示す図（その３）である。 サービスサーバの連携における処理例を示すシーケンス図（その３）である。

符号の説明

１ クライアント
２ サービスサーバ
２１ リポジトリサービス
２２ 印刷サービス
２３ 配信アプリケーションサービス
２４ 配信サービス
２５ コピーアプリサービス
２６ スキャンフィルタ
２７ 印刷フィルタ
２８ 画像処理フィルタ
３ ユーザ認証装置
３１ ユーザ認証制御部
３２ チケットプール
３２ａ キー
３２ｂ 生存期限
３２ｃ ユーザ情報
３２ｄ 上限値
３３ 生存期限監視部
４ ユーザ管理ＤＢ

Claims (10)

1. クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、
   ユーザ情報を管理するユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理ＤＢよりアクセス速度の速いデータ一時保持部を備え、
   上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット処理装置。
2. 請求項１に記載の認証チケット処理装置において、
   上記データ一時保持部が保持するデータを管理する管理部を備え、
   上記データ一時保持部はユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、
   上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット処理装置。
3. 請求項１または２のいずれか一項に記載の認証チケット処理装置において、
   上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理ＤＢからユーザ情報を取得することを特徴とする認証チケット処理装置。
4. 請求項２に記載の認証チケット処理装置において、
   上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット処理装置。
5. 請求項４に記載の認証チケット処理装置において、
   上記指定期間の延長は、上記ユーザ管理ＤＢからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット処理装置。
6. クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理方法であって、
   ユーザ情報を管理するユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を上記ユーザ管理ＤＢよりアクセス速度の速いデータ一時保持部に保持し、
   上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット管理方法。
7. 請求項６に記載の認証チケット管理方法において、
   上記ユーザ管理ＤＢからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット管理方法。
8. 請求項６または７のいずれか一項に記載の認証チケット管理方法において、
   上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理ＤＢからユーザ情報を取得することを特徴とする認証チケット管理方法。
9. 請求項７に記載の認証チケット管理方法において、
   上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット管理方法。
10. 請求項９に記載の認証チケット管理方法において、
    上記指定期間の延長は、上記ユーザ管理ＤＢからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット管理方法。

Images