認証チケット処理装置
【課題】自己記述型チケットの持つパフォーマンスの欠点を解決しユーザ情報の取得を高速化する。
【解決手段】クライアントがサーバからサービスの提供を受けるのに際し、クライアントからの認証要求に応じ認証チケットを作成してクライアントに提供するとともに、クライアントからのサービス要求に伴う認証チケットにつきサーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理システムにおいて、ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、ユーザ情報を取り込む必要がある場合、データ一時保持部での目的とするユーザ情報の有無を調べ、データ一時保持部に保持されているユーザ情報については、データ一時保持部からユーザ情報を取得する。
【解決手段】クライアントがサーバからサービスの提供を受けるのに際し、クライアントからの認証要求に応じ認証チケットを作成してクライアントに提供するとともに、クライアントからのサービス要求に伴う認証チケットにつきサーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理システムにおいて、ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、ユーザ情報を取り込む必要がある場合、データ一時保持部での目的とするユーザ情報の有無を調べ、データ一時保持部に保持されているユーザ情報については、データ一時保持部からユーザ情報を取得する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザ情報の取得を高速化することのできる認証チケット処理装置に関する。
【背景技術】
【0002】
ネットワーク上のサーバから迅速かつ安全なサービス提供を行うため、認証チケットが用いられることがある。
【0003】
認証チケットには用途に応じて各種の仕様が存在するが、そのうちの一つとして、デコード時点でのユーザ情報を返す仕様の「自己記述型チケット(SelfContainedチケット)」と呼ばれる認証チケットがある。
【0004】
図1は従来における認証要求から認証チケット取得までの処理の流れを示す図であり、サービスサーバ2からサービス提供を受けるのに先立ち、クライアント1からユーザ認証装置(UAUD:User Authentication by User Directory)3に認証要求を行うと(ステップS1)、ユーザ認証装置3はユーザ管理DB4にユーザ情報の確認を行い(ステップS2)、確認がとれるとユーザ管理DB4からユーザID情報のみを取得する(ステップS3)。そして、ユーザID情報に基づいて認証チケットを構成(作成)し(ステップS4)、クライアント1に認証チケットを提供する(ステップS5)。
【0005】
図2は従来におけるサービス要求からサービス開始までの処理の流れを示す図であり、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS11)、サービスサーバ2はユーザ認証装置3に対して認証チケットのデコード要求を行う(ステップS12)。ユーザ認証装置3はユーザ管理DB4からユーザ情報(ユーザID情報以外の情報を含む)を取得し(ステップS13、S14)、サービスサーバ2にユーザ情報を提供し(ステップS15)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS16)。
【0006】
一方、特許文献1には、蓄積文書に対する認証機能を共有することができ、ネットワークおよび融合機のリソースを浪費することなく蓄積文書の供給が可能な画像形成装置、蓄積文書管理方法および蓄積文書処理システムが開示されている。
【特許文献1】特開2004−135291号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
ところで、図2において、サービスサーバ2は同じ認証チケットであっても、そのような認証チケットを伴った新たなサービス要求を受け取る度にユーザ認証装置3に対してデコード要求を行い、ユーザ認証装置3はユーザ管理DB4からユーザ情報の取得を行う。これは、自己記述型チケットでは、認証チケットを長期間保有している場合に、そのユーザの登録状況が変化してしまい、認証時のユーザ情報とデコード時のそのユーザの持つ実際のユーザ情報とが異なってしまうことが生じる可能性があるためである。例えば、ワークフローなど、文書の配信、印刷等をする場合、開始時に何らかの理由で待機状態になることがある。待機状態からその機能が可能な状態になる時刻は、前もっては判らない。そのため、再開時に利用する認証チケットは長期間利用可能でなければならない。しかし、組織異動や休職・退職などにより、認証時点でのそのユーザの情報が、機能が利用可能となった時点で異なってしまうことは容易に考えられる。そのため、認証チケットからユーザ情報をデコードする際にユーザ情報をユーザ管理DB4から取得するようにしていた。
【0008】
従来のシステムはこのような仕組となっていたため、サービスサーバ2における複数のサービスが同一の認証チケットを同時に利用する場合、ユーザ認証装置3側には、短い時間間隔(例:数秒間隔)でデコード要求が発生することが起こり、その度に同一ユーザ情報に関するユーザ管理DB4へのデータベース参照が発生してしまうという問題があった。図3は従来において認証チケットデコード要求が頻発した様子を示す図であり、サービスサーバ2からユーザ認証装置3へのデコード要求が短い時間間隔で連続発生し(ステップS22)、これに応じてユーザ認証装置3からユーザ管理DB4に対するユーザ情報の取得が連続発生(ステップS23)している様子を示している。
【0009】
このように、同一の自己記述型チケットに対し短い時間間隔でデコードが要求された場合、従来のシステムでは、その度に同一ユーザ情報に関するユーザ管理DB4へのデータベース参照が発生してしまい、パフォーマンスが低下してしまうという問題があった。
【0010】
このような問題点は自己記述型チケットの仕様であるが故に止むを得ないとも考えられるが、このような仕様が想定するユーザ情報の変更は頻繁に起こるものではなく、パフォーマンス低下とトレードオフの関係にあると考えるのはバランスを欠いている。すなわち、文書管理システム等を利用するユーザのユーザ情報が頻繁に変更されることはなく、変更されるとしても人事異動など組織変更があった場合が主であるので、年に数回、多くても月に数回と考えるのが自然であり、その際の不都合を回避するためにデコード要求の度にデータベース参照を行うのは行き過ぎである。
【0011】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することのできる認証チケット処理装置を提供することにある。
【課題を解決するための手段】
【0012】
上記の課題を解決するため、本発明にあっては、請求項1に記載されるように、クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得する認証チケット処理装置を要旨としている。
【0013】
また、請求項2に記載されるように、請求項1に記載の認証チケット処理装置において、上記データ一時保持部が保持するデータを管理する管理部を備え、上記データ一時保持部はユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除するようにすることができる。
【0014】
また、請求項3に記載されるように、請求項1または2のいずれか一項に記載の認証チケット処理装置において、上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得するようにすることができる。
【0015】
また、請求項4に記載されるように、請求項2に記載の認証チケット処理装置において、上記指定期間は、上記データ一時保持部からのデータの取得により延長されるようにすることができる。
【0016】
また、請求項5に記載されるように、請求項4に記載の認証チケット処理装置において、上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られるようにすることができる。
【0017】
また、請求項6〜10に記載されるように、認証チケット管理方法として構成することができる。
【発明の効果】
【0018】
本発明の認証チケット処理装置にあっては、ユーザ管理DBから取得したユーザ情報をユーザ管理DBよりアクセス速度の速いデータ一時保持部に保持し、ユーザ情報を取り込む必要がある場合にデータ一時保持部からユーザ情報を取得するようにしたので、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することができる。
【発明を実施するための最良の形態】
【0019】
以下、本発明の好適な実施形態につき説明する。
【0020】
<第1の実施形態>
図4は本発明の第1の実施形態にかかるシステムの構成例を示す図である。図4において、システムは、サービスの提供を受けるユーザが使用するPC(Personal Computer)、携帯電話、PDA(Personal Digital Assistant)等のクライアント1と、サービスを提供する複数のサービスサーバ2と、認証チケットの作成およびデコードを行うユーザ認証装置3と、ユーザ情報を管理するユーザ管理DB4とを備えている。また、ユーザ認証装置3は、認証チケットの作成およびデコードの主たる処理を行うユーザ認証制御部31と、ユーザ認証制御部31の制御のもとユーザ情報を期限付きで保持するチケットプール(ユーザ情報一時保持部)32と、チケットプール32の生存期限を監視して適宜に削除を行う生存期限監視部33とを備えている。
【0021】
図5は第1の実施形態におけるチケットプール32の構造を示す図であり、自己記述型チケットが格納されるキー32aと、キー32aに関連付けられて格納される生存期限32bおよびユーザ情報32cとを有している。ここで、生存期限32bは、自己記述型チケットに含まれる有効期限とは独立したものであり、その認証チケットが生成された日時に指定期間を加えた値となる。なお、指定期間は、短い時間間隔でデコード要求が頻発する場合に対応できる範囲内で、デコード時点でのユーザ情報を返すという自己記述型チケットの仕様から大きく逸脱しないよう、十分に短い値(例えば30秒)とする。
【0022】
図6は第1の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。図6において、サービスサーバ2からサービス提供を受けるのに先立ち、クライアント1からユーザ認証装置3のユーザ認証制御部31に認証要求を行うと(ステップS101)、ユーザ認証制御部31はユーザ管理DB4にユーザ情報の確認を行い(ステップS102)、確認がとれるとユーザ管理DB4からユーザ情報を取得する(ステップS103)。このユーザ情報は、ユーザID情報だけでなく、デコード時に必要な情報すべてを含む。
【0023】
ユーザ認証制御部31は取得したユーザ情報のうちユーザID情報に基づいて認証チケットを構成(作成)するとともに(ステップS104)、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール32に格納し(ステップS105)、クライアント1に認証チケットを提供する(ステップS106)。
【0024】
図7は第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図7において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS111)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS112)。
【0025】
ユーザ認証制御部31は、ユーザ管理DB4にはアクセスせず、チケットプール32からユーザ情報の取得を行い(ステップS113、S114)、サービスサーバ2にユーザ情報を提供する(ステップS115)。
【0026】
サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS116)。
【0027】
一方、生存期限監視部33は常時もしくは定期的にチケットプール32に保持されたユーザ情報の生存期限32bと現在時刻とを比較し、生存期限を過ぎたユーザ情報を削除しあるいは無効にする。図8は第1の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、認証チケットが生成され、何度か参照がされた後、生成から指定期間経過の生存期限満了により、認証チケットは削除される。
【0028】
図9は目的の認証チケットが削除されている場合の第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図9において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS121)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS122)。
【0029】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を試みるが(ステップS123、S124)、目的のユーザ情報がないため、ユーザ管理DB4からユーザ情報を取得する(ステップS125、S126)。
【0030】
そして、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール32に格納し(ステップS127)、サービスサーバ2にユーザ情報を提供する(ステップS128)。
【0031】
サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS129)。
【0032】
図10は第1の実施形態における全体の処理を示すフローチャートであり、S201〜S209が認証要求から認証チケット取得までの処理、S210〜S231がサービス要求からサービス開始までの処理、S241〜S244がチケットプール32のユーザ情報等の削除の処理である。
【0033】
このように、認証チケットのデコード要求に対しては、チケットプール32から優先的にユーザ情報を取得するため、デコード要求が短時間に頻発するようなことがあってもパフォーマンスの低下を防止することができる。
【0034】
また、ユーザ情報を情報取得の時刻と併せて保持し、指定期間経過後に削除することから、その期間を適当に設定することにより、一時的に集中して発生するデコード要求に対しパフォーマンス向上の効果を保ったまま、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を鮮度を保った状態の十分な精度で返すことが可能になる。
【0035】
<第2の実施形態>
図11は本発明の第2の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図であり、チケットプール32に保持したユーザ情報の生存期限を更新するようにしたものである。
【0036】
すなわち、上述した第1の実施形態においては、一連の操作の都合上連続してデコード要求しているかどうかに関わらず、指定期間経過後になるとチケットプール32からユーザ情報が破棄され、その後のデコード要求に対してはユーザ管理DB4からユーザ情報を取得することになる。そのため、一連のデコードの前半と後半とでデコードされる情報が異なる可能性がある。複数のサービスから連続してデコードの要求があった場合、これら一連のサービスは関連したアプリケーションを構成することが多く、デコード結果も同一情報であることが望ましい。そこで、この第2の実施形態ではチケットプール32からユーザ情報を取得した際、その度に生存期限情報を初期化するようにしている。
【0037】
図11において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS131)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS132)。ここでは複数のサービスから連続してデコード要求が発生したものとする。
【0038】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を行うが(ステップS133、S135)、ユーザ情報の取得を行う度に生存期限の更新を行う(ステップS134)。
【0039】
ユーザ認証制御部31はサービスサーバ2にユーザ情報を提供し(ステップS136)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS137)。
【0040】
図12は第2の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、第1の実施形態では、(a)に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除されるが、この第2の実施形態では、(b)に示すように参照される度に指定期間が開始し、最後の参照から指定時間後に削除されることになる。
【0041】
このように、チケットプール32からのデータの取得により生存期限が延長されることにより、一連のデコード要求の間はチケットプール32のユーザ情報が破棄されることはなくなり、一連のデコードの前半と後半とでデコードされる情報が異なるという事態を避けることができる。
【0042】
<第3の実施形態>
図13は本発明の第3の実施形態におけるチケットプールの構造を示す図であり、生存期限の延長の上限値を設定可能にしたものである。
【0043】
すなわち、上述した第2の実施形態においては、デコード要求が混雑している場合など、常に短い時間間隔で要求が発生してしまうとチケットプール32からユーザ情報が破棄されることが阻害され、結局その場合、ユーザ管理DB4からユーザ情報を取得することがなくなってしまう。すなわち、本来、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱してしまうことになる。そこで、この第3の実施形態ではチケットプール32で管理されるユーザ情報について、その生存期限に加え上限値も同時に管理するようにしている。
【0044】
図13において、自己記述型チケットが格納されるキー32aと、キー32aに関連付けられて格納される生存期限32bおよびユーザ情報32cとに加え、生存期限の延長可能な上限値32dを設けるようにしている。なお、上限値32dは、ユーザ管理DB4からユーザ情報を取得した時点で初期化する。
【0045】
図14は本発明の第3の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図14において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS141)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS142)。ここでは複数のサービスから連続してデコード要求が発生したものとする。
【0046】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を行うが(ステップS143、S145)、ユーザ情報の取得を行う度に生存期限の更新を行う(ステップS144)。ただし、生存期限の更新は上限値32dを限度とする。
【0047】
ユーザ認証制御部31はサービスサーバ2にユーザ情報を提供し(ステップS146)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS147)。
【0048】
図15は第3の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、第1の実施形態では、(a)に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除され、第2の実施形態では、(b)に示すように参照が連続する限り削除されないが、この第3の実施形態では、(c)に示すように上限値を超えない範囲で最後の参照から一定時間後に削除され、その後のデコードに対しては新しいユーザ情報が参照される。
【0049】
このように、生存期限の延長の上限値を設定可能にしたため、デコード要求が混雑している場合でも、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱することを防止することが可能になる。
【0050】
<サービスサーバ連携の例>
上述したサービスサーバ2は互いに独立して存在しており、サービスサーバ2を任意に追加、削除することが可能である。また、アプリケーションを実現させるためには、複数のサービスサーバ2を実行し連携させる。
【0051】
アプリケーション毎にどのサービスサーバ2が連携するかによって、様々な制御が考えられ、例えば、次の3パターンがある。
(1)クライアントが規定する場合。
(2)アプリケーションを規定する第3のサービスサーバが規定する場合。
(3)認証チケット自体に起動サービスの規定がある場合。
【0052】
図16はクライアントが規定する場合のサービスサーバの連携の例を示す図である。図16において、クライアント1が文書印刷する際、クライアント1の制御のもと、リポジトリサービス21と印刷サービス22を起動している。なお、リポジトリサービス21、印刷サービス22のそれぞれは、自らのサービスのアクセス権を判断するために、ユーザ認証装置3によりそれぞれ認証チケットをデコードする。ユーザ認証装置3は、同一ユーザに対する認証チケットを短い期間内で複数回デコードすることになる。
【0053】
図17はこの場合の処理例を示すシーケンス図であり、S301〜S307が認証チケット取得の処理、S308がクライアント1による文書印刷の指示、S309〜S315がリポジトリサービス21による処理、S316〜S321が印刷サービス22による処理、S322、S323がクライアント1によるサービス受付待ちの処理である。なお、S309とS316でリポジトリサービス21と印刷サービス22に同時並行に認証チケットを渡しているが、リポジトリサービス21が対象文書を取得した後に印刷サービス22に認証チケットを渡すようにしてもよい。
【0054】
図18はアプリケーションを規定する第3のサービスサーバが規定する場合のサービスサーバの連携の例を示す図である。図18において、クライアント1が文書配信する際、配信アプリケーションサービス23の制御のもと、リポジトリサービス21と配信サービス24を起動し、それぞれのサービスが認証チケットをデコードする。なお、配信アプリケーションサービス23は、受け取った認証チケットをデコードしても良く、その際はデコード結果により、配下のサービスサーバを制限することも可能になる。配信サービス24は、配信に失敗するとインターバル期間後、再度配信を開始する。この動作も先のデコード結果で切り替えることが可能である。配信の再開時、認証チケットのデコードで返されるユーザ情報は、その時点のユーザ情報になる。
【0055】
図19はこの場合の処理例を示すシーケンス図であり、S401〜S407が認証チケット取得の処理、S408がクライアント1による文書配信の指示、S409〜S428が配信アプリケーションサービス23の制御によるリポジトリサービス21と配信サービス24の処理、S429〜S439が配信失敗の場合の再配信処理である。なお、S410とS417でリポジトリサービス21と印刷サービス22に同時並行に認証チケットを渡しているが、リポジトリサービス21が対象文書を取得した後に印刷サービス22に認証チケットを渡すようにしてもよい。
【0056】
図20は認証チケット自体に起動サービスの規定がある場合のサービスサーバの連携の例を示す図である。図20においては、サービスサーバ2とユーザ認証装置3がMFP(Multi Function Printer)機器の内部にある場合を例としており、例えば、コピーする際にはコピーアプリサービス25の実現機能としてスキャンフィルタ26、印刷フィルタ27、画像処理フィルタ28が起動する。クライアント1のユーザ毎に利用可能なフィルタの種類が制限されているとき、認証チケットにその情報(起動可能なフィルタの種類)が含まれることで、起動可能なサービスが決定される。
【0057】
図21はこの場合の処理例を示すシーケンス図であり、S501〜S507の認証チケット取得の処理では、ユーザにより利用可能なサービスの種類が規定された認証チケットが発行される。また、S508はクライアント1による文書配信の指示、S509〜S535はコピーアプリサービス25の制御によるスキャンフィルタ26、印刷フィルタ27、画像処理フィルタ28の処理、S536はクライアント1による終了待ちの処理である。
【0058】
<総括>
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【0059】
【図1】従来における認証要求から認証チケット取得までの処理の流れを示す図である。
【図2】従来におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図3】従来において認証チケットデコード要求が頻発した様子を示す図である。
【図4】本発明の第1の実施形態にかかるシステムの構成例を示す図である。
【図5】第1の実施形態におけるチケットプールの構造を示す図である。
【図6】第1の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。
【図7】第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図(その1)である。
【図8】第1の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図9】第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図(その2)である。
【図10】第1の実施形態における全体の処理を示すフローチャートである。
【図11】本発明の第2の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図12】第2の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図13】本発明の第3の実施形態におけるチケットプールの構造を示す図である。
【図14】本発明の第3の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図15】第3の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図16】サービスサーバの連携の例を示す図(その1)である。
【図17】サービスサーバの連携における処理例を示すシーケンス図(その1)である。
【図18】サービスサーバの連携の例を示す図(その2)である。
【図19】サービスサーバの連携における処理例を示すシーケンス図(その2)である。
【図20】サービスサーバの連携の例を示す図(その3)である。
【図21】サービスサーバの連携における処理例を示すシーケンス図(その3)である。
【符号の説明】
【0060】
1 クライアント
2 サービスサーバ
21 リポジトリサービス
22 印刷サービス
23 配信アプリケーションサービス
24 配信サービス
25 コピーアプリサービス
26 スキャンフィルタ
27 印刷フィルタ
28 画像処理フィルタ
3 ユーザ認証装置
31 ユーザ認証制御部
32 チケットプール
32a キー
32b 生存期限
32c ユーザ情報
32d 上限値
33 生存期限監視部
4 ユーザ管理DB
【技術分野】
【0001】
本発明は、ユーザ情報の取得を高速化することのできる認証チケット処理装置に関する。
【背景技術】
【0002】
ネットワーク上のサーバから迅速かつ安全なサービス提供を行うため、認証チケットが用いられることがある。
【0003】
認証チケットには用途に応じて各種の仕様が存在するが、そのうちの一つとして、デコード時点でのユーザ情報を返す仕様の「自己記述型チケット(SelfContainedチケット)」と呼ばれる認証チケットがある。
【0004】
図1は従来における認証要求から認証チケット取得までの処理の流れを示す図であり、サービスサーバ2からサービス提供を受けるのに先立ち、クライアント1からユーザ認証装置(UAUD:User Authentication by User Directory)3に認証要求を行うと(ステップS1)、ユーザ認証装置3はユーザ管理DB4にユーザ情報の確認を行い(ステップS2)、確認がとれるとユーザ管理DB4からユーザID情報のみを取得する(ステップS3)。そして、ユーザID情報に基づいて認証チケットを構成(作成)し(ステップS4)、クライアント1に認証チケットを提供する(ステップS5)。
【0005】
図2は従来におけるサービス要求からサービス開始までの処理の流れを示す図であり、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS11)、サービスサーバ2はユーザ認証装置3に対して認証チケットのデコード要求を行う(ステップS12)。ユーザ認証装置3はユーザ管理DB4からユーザ情報(ユーザID情報以外の情報を含む)を取得し(ステップS13、S14)、サービスサーバ2にユーザ情報を提供し(ステップS15)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS16)。
【0006】
一方、特許文献1には、蓄積文書に対する認証機能を共有することができ、ネットワークおよび融合機のリソースを浪費することなく蓄積文書の供給が可能な画像形成装置、蓄積文書管理方法および蓄積文書処理システムが開示されている。
【特許文献1】特開2004−135291号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
ところで、図2において、サービスサーバ2は同じ認証チケットであっても、そのような認証チケットを伴った新たなサービス要求を受け取る度にユーザ認証装置3に対してデコード要求を行い、ユーザ認証装置3はユーザ管理DB4からユーザ情報の取得を行う。これは、自己記述型チケットでは、認証チケットを長期間保有している場合に、そのユーザの登録状況が変化してしまい、認証時のユーザ情報とデコード時のそのユーザの持つ実際のユーザ情報とが異なってしまうことが生じる可能性があるためである。例えば、ワークフローなど、文書の配信、印刷等をする場合、開始時に何らかの理由で待機状態になることがある。待機状態からその機能が可能な状態になる時刻は、前もっては判らない。そのため、再開時に利用する認証チケットは長期間利用可能でなければならない。しかし、組織異動や休職・退職などにより、認証時点でのそのユーザの情報が、機能が利用可能となった時点で異なってしまうことは容易に考えられる。そのため、認証チケットからユーザ情報をデコードする際にユーザ情報をユーザ管理DB4から取得するようにしていた。
【0008】
従来のシステムはこのような仕組となっていたため、サービスサーバ2における複数のサービスが同一の認証チケットを同時に利用する場合、ユーザ認証装置3側には、短い時間間隔(例:数秒間隔)でデコード要求が発生することが起こり、その度に同一ユーザ情報に関するユーザ管理DB4へのデータベース参照が発生してしまうという問題があった。図3は従来において認証チケットデコード要求が頻発した様子を示す図であり、サービスサーバ2からユーザ認証装置3へのデコード要求が短い時間間隔で連続発生し(ステップS22)、これに応じてユーザ認証装置3からユーザ管理DB4に対するユーザ情報の取得が連続発生(ステップS23)している様子を示している。
【0009】
このように、同一の自己記述型チケットに対し短い時間間隔でデコードが要求された場合、従来のシステムでは、その度に同一ユーザ情報に関するユーザ管理DB4へのデータベース参照が発生してしまい、パフォーマンスが低下してしまうという問題があった。
【0010】
このような問題点は自己記述型チケットの仕様であるが故に止むを得ないとも考えられるが、このような仕様が想定するユーザ情報の変更は頻繁に起こるものではなく、パフォーマンス低下とトレードオフの関係にあると考えるのはバランスを欠いている。すなわち、文書管理システム等を利用するユーザのユーザ情報が頻繁に変更されることはなく、変更されるとしても人事異動など組織変更があった場合が主であるので、年に数回、多くても月に数回と考えるのが自然であり、その際の不都合を回避するためにデコード要求の度にデータベース参照を行うのは行き過ぎである。
【0011】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することのできる認証チケット処理装置を提供することにある。
【課題を解決するための手段】
【0012】
上記の課題を解決するため、本発明にあっては、請求項1に記載されるように、クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得する認証チケット処理装置を要旨としている。
【0013】
また、請求項2に記載されるように、請求項1に記載の認証チケット処理装置において、上記データ一時保持部が保持するデータを管理する管理部を備え、上記データ一時保持部はユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除するようにすることができる。
【0014】
また、請求項3に記載されるように、請求項1または2のいずれか一項に記載の認証チケット処理装置において、上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得するようにすることができる。
【0015】
また、請求項4に記載されるように、請求項2に記載の認証チケット処理装置において、上記指定期間は、上記データ一時保持部からのデータの取得により延長されるようにすることができる。
【0016】
また、請求項5に記載されるように、請求項4に記載の認証チケット処理装置において、上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られるようにすることができる。
【0017】
また、請求項6〜10に記載されるように、認証チケット管理方法として構成することができる。
【発明の効果】
【0018】
本発明の認証チケット処理装置にあっては、ユーザ管理DBから取得したユーザ情報をユーザ管理DBよりアクセス速度の速いデータ一時保持部に保持し、ユーザ情報を取り込む必要がある場合にデータ一時保持部からユーザ情報を取得するようにしたので、自己記述型チケットの持つパフォーマンスの欠点を解決し、ユーザ情報の取得を高速化することができる。
【発明を実施するための最良の形態】
【0019】
以下、本発明の好適な実施形態につき説明する。
【0020】
<第1の実施形態>
図4は本発明の第1の実施形態にかかるシステムの構成例を示す図である。図4において、システムは、サービスの提供を受けるユーザが使用するPC(Personal Computer)、携帯電話、PDA(Personal Digital Assistant)等のクライアント1と、サービスを提供する複数のサービスサーバ2と、認証チケットの作成およびデコードを行うユーザ認証装置3と、ユーザ情報を管理するユーザ管理DB4とを備えている。また、ユーザ認証装置3は、認証チケットの作成およびデコードの主たる処理を行うユーザ認証制御部31と、ユーザ認証制御部31の制御のもとユーザ情報を期限付きで保持するチケットプール(ユーザ情報一時保持部)32と、チケットプール32の生存期限を監視して適宜に削除を行う生存期限監視部33とを備えている。
【0021】
図5は第1の実施形態におけるチケットプール32の構造を示す図であり、自己記述型チケットが格納されるキー32aと、キー32aに関連付けられて格納される生存期限32bおよびユーザ情報32cとを有している。ここで、生存期限32bは、自己記述型チケットに含まれる有効期限とは独立したものであり、その認証チケットが生成された日時に指定期間を加えた値となる。なお、指定期間は、短い時間間隔でデコード要求が頻発する場合に対応できる範囲内で、デコード時点でのユーザ情報を返すという自己記述型チケットの仕様から大きく逸脱しないよう、十分に短い値(例えば30秒)とする。
【0022】
図6は第1の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。図6において、サービスサーバ2からサービス提供を受けるのに先立ち、クライアント1からユーザ認証装置3のユーザ認証制御部31に認証要求を行うと(ステップS101)、ユーザ認証制御部31はユーザ管理DB4にユーザ情報の確認を行い(ステップS102)、確認がとれるとユーザ管理DB4からユーザ情報を取得する(ステップS103)。このユーザ情報は、ユーザID情報だけでなく、デコード時に必要な情報すべてを含む。
【0023】
ユーザ認証制御部31は取得したユーザ情報のうちユーザID情報に基づいて認証チケットを構成(作成)するとともに(ステップS104)、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール32に格納し(ステップS105)、クライアント1に認証チケットを提供する(ステップS106)。
【0024】
図7は第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図7において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS111)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS112)。
【0025】
ユーザ認証制御部31は、ユーザ管理DB4にはアクセスせず、チケットプール32からユーザ情報の取得を行い(ステップS113、S114)、サービスサーバ2にユーザ情報を提供する(ステップS115)。
【0026】
サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS116)。
【0027】
一方、生存期限監視部33は常時もしくは定期的にチケットプール32に保持されたユーザ情報の生存期限32bと現在時刻とを比較し、生存期限を過ぎたユーザ情報を削除しあるいは無効にする。図8は第1の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、認証チケットが生成され、何度か参照がされた後、生成から指定期間経過の生存期限満了により、認証チケットは削除される。
【0028】
図9は目的の認証チケットが削除されている場合の第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図9において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS121)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS122)。
【0029】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を試みるが(ステップS123、S124)、目的のユーザ情報がないため、ユーザ管理DB4からユーザ情報を取得する(ステップS125、S126)。
【0030】
そして、ユーザ情報を認証チケットおよび生存期限と関連付けてチケットプール32に格納し(ステップS127)、サービスサーバ2にユーザ情報を提供する(ステップS128)。
【0031】
サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS129)。
【0032】
図10は第1の実施形態における全体の処理を示すフローチャートであり、S201〜S209が認証要求から認証チケット取得までの処理、S210〜S231がサービス要求からサービス開始までの処理、S241〜S244がチケットプール32のユーザ情報等の削除の処理である。
【0033】
このように、認証チケットのデコード要求に対しては、チケットプール32から優先的にユーザ情報を取得するため、デコード要求が短時間に頻発するようなことがあってもパフォーマンスの低下を防止することができる。
【0034】
また、ユーザ情報を情報取得の時刻と併せて保持し、指定期間経過後に削除することから、その期間を適当に設定することにより、一時的に集中して発生するデコード要求に対しパフォーマンス向上の効果を保ったまま、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を鮮度を保った状態の十分な精度で返すことが可能になる。
【0035】
<第2の実施形態>
図11は本発明の第2の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図であり、チケットプール32に保持したユーザ情報の生存期限を更新するようにしたものである。
【0036】
すなわち、上述した第1の実施形態においては、一連の操作の都合上連続してデコード要求しているかどうかに関わらず、指定期間経過後になるとチケットプール32からユーザ情報が破棄され、その後のデコード要求に対してはユーザ管理DB4からユーザ情報を取得することになる。そのため、一連のデコードの前半と後半とでデコードされる情報が異なる可能性がある。複数のサービスから連続してデコードの要求があった場合、これら一連のサービスは関連したアプリケーションを構成することが多く、デコード結果も同一情報であることが望ましい。そこで、この第2の実施形態ではチケットプール32からユーザ情報を取得した際、その度に生存期限情報を初期化するようにしている。
【0037】
図11において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS131)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS132)。ここでは複数のサービスから連続してデコード要求が発生したものとする。
【0038】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を行うが(ステップS133、S135)、ユーザ情報の取得を行う度に生存期限の更新を行う(ステップS134)。
【0039】
ユーザ認証制御部31はサービスサーバ2にユーザ情報を提供し(ステップS136)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS137)。
【0040】
図12は第2の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、第1の実施形態では、(a)に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除されるが、この第2の実施形態では、(b)に示すように参照される度に指定期間が開始し、最後の参照から指定時間後に削除されることになる。
【0041】
このように、チケットプール32からのデータの取得により生存期限が延長されることにより、一連のデコード要求の間はチケットプール32のユーザ情報が破棄されることはなくなり、一連のデコードの前半と後半とでデコードされる情報が異なるという事態を避けることができる。
【0042】
<第3の実施形態>
図13は本発明の第3の実施形態におけるチケットプールの構造を示す図であり、生存期限の延長の上限値を設定可能にしたものである。
【0043】
すなわち、上述した第2の実施形態においては、デコード要求が混雑している場合など、常に短い時間間隔で要求が発生してしまうとチケットプール32からユーザ情報が破棄されることが阻害され、結局その場合、ユーザ管理DB4からユーザ情報を取得することがなくなってしまう。すなわち、本来、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱してしまうことになる。そこで、この第3の実施形態ではチケットプール32で管理されるユーザ情報について、その生存期限に加え上限値も同時に管理するようにしている。
【0044】
図13において、自己記述型チケットが格納されるキー32aと、キー32aに関連付けられて格納される生存期限32bおよびユーザ情報32cとに加え、生存期限の延長可能な上限値32dを設けるようにしている。なお、上限値32dは、ユーザ管理DB4からユーザ情報を取得した時点で初期化する。
【0045】
図14は本発明の第3の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。図14において、クライアント1がサービスサーバ2に対して認証チケットを伴ったサービス要求を行うと(ステップS141)、サービスサーバ2はユーザ認証装置3のユーザ認証制御部31に対して認証チケットのデコード要求を行う(ステップS142)。ここでは複数のサービスから連続してデコード要求が発生したものとする。
【0046】
ユーザ認証制御部31は、チケットプール32からユーザ情報の取得を行うが(ステップS143、S145)、ユーザ情報の取得を行う度に生存期限の更新を行う(ステップS144)。ただし、生存期限の更新は上限値32dを限度とする。
【0047】
ユーザ認証制御部31はサービスサーバ2にユーザ情報を提供し(ステップS146)、サービスサーバ2は取得したユーザ情報からそのサービスに対するアクセス権の判断を行った上でサービス提供を開始する(ステップS147)。
【0048】
図15は第3の実施形態におけるチケットプール32のユーザ情報等の削除の例を示す図であり、第1の実施形態では、(a)に示すように認証チケットの生成から指定期間経過の生存期限満了により認証チケットは削除され、第2の実施形態では、(b)に示すように参照が連続する限り削除されないが、この第3の実施形態では、(c)に示すように上限値を超えない範囲で最後の参照から一定時間後に削除され、その後のデコードに対しては新しいユーザ情報が参照される。
【0049】
このように、生存期限の延長の上限値を設定可能にしたため、デコード要求が混雑している場合でも、自己記述型チケットの仕様であるチケットのデコード時点でのユーザ情報を返す仕様から大きく逸脱することを防止することが可能になる。
【0050】
<サービスサーバ連携の例>
上述したサービスサーバ2は互いに独立して存在しており、サービスサーバ2を任意に追加、削除することが可能である。また、アプリケーションを実現させるためには、複数のサービスサーバ2を実行し連携させる。
【0051】
アプリケーション毎にどのサービスサーバ2が連携するかによって、様々な制御が考えられ、例えば、次の3パターンがある。
(1)クライアントが規定する場合。
(2)アプリケーションを規定する第3のサービスサーバが規定する場合。
(3)認証チケット自体に起動サービスの規定がある場合。
【0052】
図16はクライアントが規定する場合のサービスサーバの連携の例を示す図である。図16において、クライアント1が文書印刷する際、クライアント1の制御のもと、リポジトリサービス21と印刷サービス22を起動している。なお、リポジトリサービス21、印刷サービス22のそれぞれは、自らのサービスのアクセス権を判断するために、ユーザ認証装置3によりそれぞれ認証チケットをデコードする。ユーザ認証装置3は、同一ユーザに対する認証チケットを短い期間内で複数回デコードすることになる。
【0053】
図17はこの場合の処理例を示すシーケンス図であり、S301〜S307が認証チケット取得の処理、S308がクライアント1による文書印刷の指示、S309〜S315がリポジトリサービス21による処理、S316〜S321が印刷サービス22による処理、S322、S323がクライアント1によるサービス受付待ちの処理である。なお、S309とS316でリポジトリサービス21と印刷サービス22に同時並行に認証チケットを渡しているが、リポジトリサービス21が対象文書を取得した後に印刷サービス22に認証チケットを渡すようにしてもよい。
【0054】
図18はアプリケーションを規定する第3のサービスサーバが規定する場合のサービスサーバの連携の例を示す図である。図18において、クライアント1が文書配信する際、配信アプリケーションサービス23の制御のもと、リポジトリサービス21と配信サービス24を起動し、それぞれのサービスが認証チケットをデコードする。なお、配信アプリケーションサービス23は、受け取った認証チケットをデコードしても良く、その際はデコード結果により、配下のサービスサーバを制限することも可能になる。配信サービス24は、配信に失敗するとインターバル期間後、再度配信を開始する。この動作も先のデコード結果で切り替えることが可能である。配信の再開時、認証チケットのデコードで返されるユーザ情報は、その時点のユーザ情報になる。
【0055】
図19はこの場合の処理例を示すシーケンス図であり、S401〜S407が認証チケット取得の処理、S408がクライアント1による文書配信の指示、S409〜S428が配信アプリケーションサービス23の制御によるリポジトリサービス21と配信サービス24の処理、S429〜S439が配信失敗の場合の再配信処理である。なお、S410とS417でリポジトリサービス21と印刷サービス22に同時並行に認証チケットを渡しているが、リポジトリサービス21が対象文書を取得した後に印刷サービス22に認証チケットを渡すようにしてもよい。
【0056】
図20は認証チケット自体に起動サービスの規定がある場合のサービスサーバの連携の例を示す図である。図20においては、サービスサーバ2とユーザ認証装置3がMFP(Multi Function Printer)機器の内部にある場合を例としており、例えば、コピーする際にはコピーアプリサービス25の実現機能としてスキャンフィルタ26、印刷フィルタ27、画像処理フィルタ28が起動する。クライアント1のユーザ毎に利用可能なフィルタの種類が制限されているとき、認証チケットにその情報(起動可能なフィルタの種類)が含まれることで、起動可能なサービスが決定される。
【0057】
図21はこの場合の処理例を示すシーケンス図であり、S501〜S507の認証チケット取得の処理では、ユーザにより利用可能なサービスの種類が規定された認証チケットが発行される。また、S508はクライアント1による文書配信の指示、S509〜S535はコピーアプリサービス25の制御によるスキャンフィルタ26、印刷フィルタ27、画像処理フィルタ28の処理、S536はクライアント1による終了待ちの処理である。
【0058】
<総括>
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【0059】
【図1】従来における認証要求から認証チケット取得までの処理の流れを示す図である。
【図2】従来におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図3】従来において認証チケットデコード要求が頻発した様子を示す図である。
【図4】本発明の第1の実施形態にかかるシステムの構成例を示す図である。
【図5】第1の実施形態におけるチケットプールの構造を示す図である。
【図6】第1の実施形態における認証要求から認証チケット取得までの処理の流れを示す図である。
【図7】第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図(その1)である。
【図8】第1の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図9】第1の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図(その2)である。
【図10】第1の実施形態における全体の処理を示すフローチャートである。
【図11】本発明の第2の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図12】第2の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図13】本発明の第3の実施形態におけるチケットプールの構造を示す図である。
【図14】本発明の第3の実施形態におけるサービス要求からサービス開始までの処理の流れを示す図である。
【図15】第3の実施形態におけるチケットプールのユーザ情報等の削除の例を示す図である。
【図16】サービスサーバの連携の例を示す図(その1)である。
【図17】サービスサーバの連携における処理例を示すシーケンス図(その1)である。
【図18】サービスサーバの連携の例を示す図(その2)である。
【図19】サービスサーバの連携における処理例を示すシーケンス図(その2)である。
【図20】サービスサーバの連携の例を示す図(その3)である。
【図21】サービスサーバの連携における処理例を示すシーケンス図(その3)である。
【符号の説明】
【0060】
1 クライアント
2 サービスサーバ
21 リポジトリサービス
22 印刷サービス
23 配信アプリケーションサービス
24 配信サービス
25 コピーアプリサービス
26 スキャンフィルタ
27 印刷フィルタ
28 画像処理フィルタ
3 ユーザ認証装置
31 ユーザ認証制御部
32 チケットプール
32a キー
32b 生存期限
32c ユーザ情報
32d 上限値
33 生存期限監視部
4 ユーザ管理DB
【特許請求の範囲】
【請求項1】
クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、
ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、
上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット処理装置。
【請求項2】
請求項1に記載の認証チケット処理装置において、
上記データ一時保持部が保持するデータを管理する管理部を備え、
上記データ一時保持部はユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、
上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット処理装置。
【請求項3】
請求項1または2のいずれか一項に記載の認証チケット処理装置において、
上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得することを特徴とする認証チケット処理装置。
【請求項4】
請求項2に記載の認証チケット処理装置において、
上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット処理装置。
【請求項5】
請求項4に記載の認証チケット処理装置において、
上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット処理装置。
【請求項6】
クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理方法であって、
ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部に保持し、
上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット管理方法。
【請求項7】
請求項6に記載の認証チケット管理方法において、
上記ユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット管理方法。
【請求項8】
請求項6または7のいずれか一項に記載の認証チケット管理方法において、
上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得することを特徴とする認証チケット管理方法。
【請求項9】
請求項7に記載の認証チケット管理方法において、
上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット管理方法。
【請求項10】
請求項9に記載の認証チケット管理方法において、
上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット管理方法。
【請求項1】
クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット処理装置であって、
ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を保持する、上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部を備え、
上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット処理装置。
【請求項2】
請求項1に記載の認証チケット処理装置において、
上記データ一時保持部が保持するデータを管理する管理部を備え、
上記データ一時保持部はユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、
上記管理部は、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット処理装置。
【請求項3】
請求項1または2のいずれか一項に記載の認証チケット処理装置において、
上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得することを特徴とする認証チケット処理装置。
【請求項4】
請求項2に記載の認証チケット処理装置において、
上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット処理装置。
【請求項5】
請求項4に記載の認証チケット処理装置において、
上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット処理装置。
【請求項6】
クライアントがアプリケーションに対応する複数の独立動作可能なサーバから一連のサービスの提供を受けるのに際し、上記クライアントからの認証要求に応じ認証チケットを作成して上記クライアントに提供するとともに、上記クライアントからのサービス要求に伴う上記認証チケットにつき上記サーバからデコード要求を受けた場合、該当するユーザ情報を提供する認証チケット管理方法であって、
ユーザ情報を管理するユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を上記ユーザ管理DBよりアクセス速度の速いデータ一時保持部に保持し、
上記サーバからデコード要求を受けてユーザ情報を取得する必要がある場合、上記データ一時保持部での目的とするユーザ情報の有無を調べ、上記データ一時保持部に保持されているユーザ情報については、上記データ一時保持部からユーザ情報を取得することを特徴とする認証チケット管理方法。
【請求項7】
請求項6に記載の認証チケット管理方法において、
上記ユーザ管理DBからユーザ情報を取得した場合に、そのユーザ情報を情報取得の時刻と併せて保持し、上記データ一時保持部に保持されたユーザ情報を情報取得の時刻から指定期間経過後に削除することを特徴とする認証チケット管理方法。
【請求項8】
請求項6または7のいずれか一項に記載の認証チケット管理方法において、
上記データ一時保持部に保持されていないユーザ情報については、上記データ一時保持部へのアクセスに代えて、上記ユーザ管理DBからユーザ情報を取得することを特徴とする認証チケット管理方法。
【請求項9】
請求項7に記載の認証チケット管理方法において、
上記指定期間は、上記データ一時保持部からのデータの取得により延長されることを特徴とする認証チケット管理方法。
【請求項10】
請求項9に記載の認証チケット管理方法において、
上記指定期間の延長は、上記ユーザ管理DBからユーザ情報を取得してから一定期間に限られることを特徴とする認証チケット管理方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【公開番号】特開2007−172588(P2007−172588A)
【公開日】平成19年7月5日(2007.7.5)
【国際特許分類】
【出願番号】特願2006−304257(P2006−304257)
【出願日】平成18年11月9日(2006.11.9)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
【公開日】平成19年7月5日(2007.7.5)
【国際特許分類】
【出願日】平成18年11月9日(2006.11.9)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
[ Back to top ]