JP4476025B2 - 画像形成装置 - Google Patents

Description

本発明は、Ｗｅｂサービス提供方法、Ｗｅｂサービス提供プログラム、記録媒体及びＷｅｂサービス提供装置に関する。

オープンネットワークの認証システムとして、Ｋｅｒｂｅｒｏｓ（ケルベロス）が一般的に知られている（例えば、非特許文献１参照。）。

以下、第三者機関による認証の基本概念を、図１を用いて説明する。

図１は、第三者機関による認証の基本概念を説明するための図である。

Ｋｅｒｂｅｒｏｓで採用された「信頼のおける第三者機関による認証」の基本的な枠組は、クライアントがあるサービスを利用したい場合、クライアントはＫＤＣ（Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ）にサービスを利用するためのチケットを要求して（図１の（１））、チケットを手に入れ（図１の（２））、ＫＤＣから授かったサービスを受けるためのチケットをサーバに提出し（図１の（３））、サービスを受ける。

しかしながら、このようなモデルでは、クライアントが秘密鍵をキャッシュすることになり、該秘密鍵が漏洩し易くなり、セキュリティの面において問題があった。

この問題に対して取り入れられたのが、ＴＧＴ（Ｔｉｃｋｅｔ Ｇｒａｎｔｉｎｇ Ｔｉｃｋｅｔ）である。

以下、第三者機関による安全な認証の基本概念を、図２を用いて説明する。

図２は、第三者機関による安全な認証の基本概念を説明するための図である。

クライアントは認証サーバ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）に要求して（図２の（１））、認証サーバからＴＧＴを取得し（図２の（２））、次に、クライアントはそのＴＧＴをＴＧＳ（Ｔｉｃｋｅｔ Ｇｒａｎｔｉｎｇ Ｓｅｒｖｅｒ）に提出して（図２の（３））、目的のサービスを利用するためのチケット（サーバ使用許可証）を取得し（図２の（４））、最後に、クライアントはこのチケット（サーバ使用許可証）を目的のサービスへ提出してサービスを利用する。

この際、Ｋｅｒｂｅｒｏｓシステムでは、ＫＤＣがＡＳとしての役割と、ＴＧＳとしての役割との２つの役割を果たしている。

図２に示すような認証の方法を取ることによって、Ｋｅｒｂｅｒｏｓシステムは、上記問題を解決し、よりセキュアな認証を提供することができる。
技術評論社第２編集部編「ファイアウォール＆ネットワークセキュリティ実戦テクニック−すべてのＰＣ ＵＮＩＸ（登録商標）ユーザとサイト管理者に贈る最強セキュリティガイド Ｓｏｆｔｗａｒｅ Ｄｅｓｉｇｎ Ｓｅｃｕｒｉｔｙ Ｉｓｓｕｅ」技術評論社出版、２０００年１１月、３．７オープンネットワークのための認証システムＫｅｒｂｅｒｏｓ

しかしながら、上記従来の認証方法においては、利用の許可を必要とするＷｅｂサービスが追加される度に、認証に係るサービスを提供するＫＤＣに、前記Ｗｅｂサービスに係る情報（例えば、証明情報等）を設定する必要があった。

複数のＷｅｂサービスを提供する場合、上述したような設定の必要性は、効率の面において問題があった。

本発明は、上記の点に鑑みなされたもので、簡単且つ効率的に認証サービス及び／又はＷｅｂサービスを提供することを目的とする。

そこで、上記課題を解決するため、本発明は、プリンタとスキャナの少なくとも一つを含むハードウエアリソースと、オペレーティングシステムと、前記オペレーティングシステムで動作可能であり画像形成処理に関係するサービスを提供する複数のアプリケーションプログラムと、前記オペレーティングシステムで動作可能であり前記複数のアプリケーションプログラムの一つから処理要求を受信し該受信した処理要求に基づきハードウエアリソースを制御するコントロールプログラムと、を有する画像形成装置であって、クライアントから、Ｗｅｂサービス提供装置により提供され、該クライアントが利用するＷｅｂサービスを識別するためのＷｅｂサービス識別子とともに、該Ｗｅｂサービスの利用の許可に係るＷｅｂサービス利用許可情報取得の要求を取得する取得部と、前記要求に応じて、前記Ｗｅｂサービス利用許可情報を作成するＷｅｂサービス利用許可情報作成部と、作成した該Ｗｅｂサービス利用許可情報と、該Ｗｅｂサービス利用許可情報により利用を許可するＷｅｂサービスの前記Ｗｅｂサービス識別情報とを関連付けて管理する管理部と、前記Ｗｅｂサービス提供装置から、該Ｗｅｂサービス提供装置の提供するＷｅｂサービスのＷｅｂサービス識別情報を含むＷｅｂサービス利用許可情報の解読要求を受信する解読要求受信部と、前記解読要求に応じて、該Ｗｅｂサービス利用許可情報を解読する解読部とを有し、前記解読部は、前記Ｗｅｂサービス提供装置からのＷｅｂサービス利用許可情報に含まれるＷｅｂサービス識別情報と、前記管理段階において前記Ｗｅｂサービス利用許可情報と関連付けて管理されているＷｅｂサービス識別情報とを比較して、有効なＷｅｂサービス利用許可情報であるか否かを判定する判定部を含むことを特徴とする。

本発明によればプリンタとスキャナの少なくとも一つを含むハードウエアリソースと、オペレーティングシステムと、前記オペレーティングシステムで動作可能であり画像形成処理に関係するサービスを提供する複数のアプリケーションプログラムと、前記オペレーティングシステムで動作可能であり前記複数のアプリケーションプログラムの一つから処理要求を受信し該受信した処理要求に基づきハードウエアリソースを制御するコントロールプログラムと、を有する画像形成装置であって、クライアントから、Ｗｅｂサービス提供装置により提供され、該クライアントが利用するＷｅｂサービスを識別するためのＷｅｂサービス識別子とともに、該Ｗｅｂサービスの利用の許可に係るＷｅｂサービス利用許可情報取得の要求を取得する取得部と、前記要求に応じて、前記Ｗｅｂサービス利用許可情報を作成するＷｅｂサービス利用許可情報作成部と、作成した該Ｗｅｂサービス利用許可情報と、該Ｗｅｂサービス利用許可情報により利用を許可するＷｅｂサービスの前記Ｗｅｂサービス識別情報とを関連付けて管理する管理部と、前記Ｗｅｂサービス提供装置から、該Ｗｅｂサービス提供装置の提供するＷｅｂサービスのＷｅｂサービス識別情報を含むＷｅｂサービス利用許可情報の解読要求を受信する解読要求受信部と、前記解読要求に応じて、該Ｗｅｂサービス利用許可情報を解読する解読部とを有し、前記解読部は、前記Ｗｅｂサービス提供装置からのＷｅｂサービス利用許可情報に含まれるＷｅｂサービス識別情報と、前記管理段階において前記Ｗｅｂサービス利用許可情報と関連付けて管理されているＷｅｂサービス識別情報とを比較して、有効なＷｅｂサービス利用許可情報であるか否かを判定する判定部を含むことにより、簡単且つ効率的に認証サービス及び／又はＷｅｂサービスを提供することができる。

なお、特許請求の範囲に記載のＷｅｂサービス利用許可情報は、例えば後述するＷｅｂサービス利用チケットＩＤ又はＷｅｂサービス利用チケット又はＷｅｂサービス利用チケットの一部等に対応する。また、特許請求の範囲に記載のセッションは、例えば後述するセッションＩＤ又はセッション又はセッションの一部等に対応する。また、特許請求の範囲に記載のセッションに係る情報は、例えば後述するセッションＩＤ又はセッション又はセッションの一部等に対応する。

また、上記問題を解決するため、本発明は、Ｗｅｂサービス提供プログラム、記録媒体及びＷｅｂサービス提供装置としてもよい。

本発明によれば、簡単且つ効率的に認証サービス及び／又はＷｅｂサービスを提供することができる。

以下、本発明の実施の形態について図面に基づいて説明する。

図３は、認証サービス提供サーバの一例のハードウェア構成図である。

図３に示される認証サービス提供サーバ１のハードウェア構成は、それぞれバスＢで相互に接続されている入力装置１１と、表示装置１２と、ドライブ装置１３と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１６と、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１７と、インターフェース装置１８と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１９とから構成されている。

入力装置１１は、認証サービス提供サーバ１の利用者が操作するキーボード及びマウス等で構成され、認証サービス提供サーバ１に各種操作信号を入力するのに用いられる。

表示装置１２は、認証サービス提供サーバ１の利用者が利用するディスプレイ等で構成され、各種情報を表示する。

インターフェース装置１８は、認証サービス提供サーバ１をネットワーク等に接続するインターフェースである。

後述する認証サービス３０に対応するアプリケーションプログラムや、認証サービス提供サーバ１の全体の処理を制御するメインプログラム等は、例えば、ＣＤ−ＲＯＭ等の記録媒体１４によって認証サービス提供サーバ１に提供されるか、ネットワークを通じてダウンロードされる。記録媒体１４は、ドライブ装置１３にセットされ、前記アプリケーションプログラムや前記メインプログラム等が記録媒体１４からドライブ装置１３を介してＨＤＤ１９にインストールされる。

ＲＯＭ１５は、データ等を格納する。ＲＡＭ１６は、認証サービス提供サーバ１の起動時にＨＤＤ１９から前記アプリケーションプログラムや前記メインプログラム等を読み出して格納する。ＣＰＵ１７は、ＲＡＭ１６に読み出され、格納された前記アプリケーションプログラムや前記メインプログラム等に従って処理を実行する。

ＨＤＤ１９は、プログラム以外に、例えば、後述する認証チケット５０、Ｗｅｂサービス利用チケット６０、ユーザ情報、グループ情報等を格納する。

以下、Ｗｅｂサービス提供サーバ２の一例のハードウェア構成を、図４を用いて説明する。

図４は、Ｗｅｂサービス提供サーバの一例のハードウェア構成図である。

図４に示されるＷｅｂサービス提供サーバ２のハードウェア構成は、それぞれバスＢで相互に接続されている入力装置２１と、表示装置２２と、ドライブ装置２３と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２５と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２６と、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２７と、インターフェース装置２８と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２９とから構成されている。

入力装置２１は、Ｗｅｂサービス提供サーバ２の利用者が操作するキーボード及びマウス等で構成され、Ｗｅｂサービス提供サーバ２に各種操作信号を入力するのに用いられる。

表示装置２２は、Ｗｅｂサービス提供サーバ２の利用者が利用するディスプレイ等で構成され、各種情報を表示する。

インターフェース装置２８は、Ｗｅｂサービス提供サーバ２をネットワーク等に接続するインターフェースである。

後述するディレクトリサービス４０に対応するアプリケーションプログラムや、Ｗｅｂサービス提供サーバ２の全体の処理を制御するメインプログラム等は、例えば、ＣＤ−ＲＯＭ等の記録媒体２４によってＷｅｂサービス提供サーバ２に提供されるか、ネットワークを通じてダウンロードされる。記録媒体２４は、ドライブ装置２３にセットされ、前記アプリケーションプログラムや前記メインプログラム等が記録媒体２４からドライブ装置２３を介してＨＤＤ２９にインストールされる。

ＲＯＭ２５は、データ等を格納する。ＲＡＭ２６は、Ｗｅｂサービス提供サーバ２の起動時にＨＤＤ２９から前記アプリケーションプログラムや前記メインプログラム等を読み出して格納する。ＣＰＵ２７は、ＲＡＭ２６に読み出され、格納された前記アプリケーションプログラムや前記メインプログラム等に従って処理を実行する。

ＨＤＤ２９は、プログラム以外に、例えば、後述するセッション７０及び／又はディレクトリサービス４０を利用するときに必要となる認証に係るサービスを提供する認証サービス３０のＵＲＬやディレクトリサービス４０を利用するときに必要となるディレクトリサービス４０を識別するｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列等を格納する。

上述したように、本発明の実施の形態においては、後述する認証サービス３０は、認証サービス提供サーバ１に実装され、後述するディレクトリサービス４０は、Ｗｅｂサービス提供サーバ２に実装されているものとして説明を行う。なお、認証サービス３０及びディレクトリサービス４０は同じサーバ等に実装されていてもよい。

以下、本発明における認証サービス提供方法及び／又はＷｅｂサービス提供方法の一例を、図５を用いて説明する。

図５は、認証サービス提供方法及び／又はＷｅｂサービス提供方法を説明するためのシーケンス図（その１）である。

図５に示されるように、Ｗｅｂサービス提供サーバ２が提供するＷｅｂサービスを利用するクライアント３は、クライアント３のユーザを認証する認証チケット５０の取得リクエストを作成し、認証サービス３０に送信する（図５のシーケンスＳＱ１。）。

なお、認証チケット取得リクエストの詳細は、後述する図８を用いて説明する。

認証サービス３０は、クライアント３からの認証チケット取得リクエストに含まれるユーザ名、パスワード等を基に認証を行い、認証チケット５０を作成し、該認証チケット５０のＩＤ（認証チケットＩＤ）を含む認証チケット取得レスポンスを作成し、クライアント３に送信する（図５のシーケンスＳＱ２。）。

なお、認証チケット取得レスポンスの詳細は、後述する図９を用いて説明する。

クライアント３は、認証チケット取得レスポンスを受信すると、前記認証チケットＩＤを含む、Ｗｅｂサービス提供サーバ２が提供するＷｅｂサービス（例えば、ディレクトリサービス４０）の利用を許可するＷｅｂサービス利用チケット６０の取得リクエストを、認証サービス３０に送信する（図５のシーケンスＳＱ３。）。

なお、Ｗｅｂサービス利用チケット取得リクエストの詳細は、後述する図１４を用いて説明する。例えば、クライアント３は、利用したいＷｅｂサービス（例えば、ディレクトリサービス４０）が要求する該Ｗｅｂサービスを識別する識別情報等を、Ｗｅｂサービス利用チケット取得リクエストに含め、認証サービス３０に送信する。

認証サービス３０は、Ｗｅｂサービス利用チケット取得リクエストに含まれる認証チケットＩＤを基に、対応する有効な認証チケット５０が存在するかどうか等を判定し、対応する有効な認証チケット５０が存在すると判定すると、前記Ｗｅｂサービス利用チケット取得リクエストに対応するＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０のＩＤ（Ｗｅｂサービス利用チケットＩＤ）を含むＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する（図５のシーケンスＳＱ４。）。

例えば、認証サービス３０は、Ｗｅｂサービス利用チケット取得リクエストに、Ｗｅｂサービスを識別する識別情報等が含まれていた場合、該Ｗｅｂサービスを識別する識別情報を含むＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０のＩＤ（Ｗｅｂサービス利用チケットＩＤ）を含むＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する。

なお、Ｗｅｂサービス利用チケット取得レスポンスの詳細は、後述する図１５を用いて説明する。ここで、クライアント３は、例えば認証チケット５０の有効期限が有効な間は、シーケンスＳＱ２において受信した認証チケット取得レスポンスに含まれる認証チケットＩＤを用いて、該認証チケットＩＤを含むＷｅｂサービス利用チケット取得リクエストを、認証サービス３０に送信することができる。認証サービス３０は、Ｗｅｂサービス利用チケット取得リクエストに含まれる認証チケットＩＤを基に、対応する有効な認証チケット５０が存在するかどうか等を判定し、対応する有効な認証チケット５０が存在すると判定すると、前記Ｗｅｂサービス利用チケット取得リクエストに対応するＷｅｂサービス利用チケット６０を作成し、Ｗｅｂサービス利用チケットＩＤを含むＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する。このように認証チケット５０を繰り返し利用することによって、クライアント３は、一度認証がされれば、該認証が有効な間は、再び認証を行わなくても、使用したいＷｅｂサービスに対応するＷｅｂサービス利用チケット６０（又はＷｅｂサービス利用チケットＩＤ）を取得することができる。

クライアント３は、Ｗｅｂサービス利用チケット取得レスポンスを受信すると、前記Ｗｅｂサービス利用チケットＩＤを含む、ディレクトリサービス４０とのセッションの開始リクエストを、ディレクトリサービス４０に送信する（図５のシーケンスＳＱ５。）。

なお、セッション開始リクエストの詳細は、後述する図１９及び／又は図２０を用いて説明する。

ディレクトリサービス４０は、セッション開始リクエストに含まれるＷｅｂサービス利用チケットＩＤを基に、該Ｗｅｂサービス利用チケットＩＤと当該ディレクトリサービス４０を識別する識別情報とを含むＷｅｂサービス利用チケット６０の解読リクエストを作成し、認証サービス３０に送信する（図５のシーケンスＳＱ６。）。

なお、Ｗｅｂサービス利用チケット解読リクエストの詳細は、後述する図２１を用いて説明する。

認証サービス３０は、Ｗｅｂサービス利用チケット解読リクエストに含まれるＷｅｂサービス利用チケットＩＤ及び／又はディレクトリサービス４０を識別する識別情報を基に、有効なＷｅｂサービス利用チケット６０かどうかを判定し、例えば、該判定の結果（解読結果）や、認証チケット５０及び／又はＷｅｂサービス利用チケット６０の内容を含むＷｅｂサービス利用チケット解読レスポンスを作成し、ディレクトリサービス４０に送信する（図５のシーケンスＳＱ７。）。

なお、Ｗｅｂサービス利用チケット解読レスポンスの詳細は、後述する図２２を用いて説明する。

ディレクトリサービス４０は、Ｗｅｂサービス利用チケット解読レスポンスに含まれる前記判定の結果を基に、セッション７０を作成し、該セッション７０のＩＤを含むセッション開始レスポンスをクライアント３に送信する（図５のシーケンスＳＱ８。）。

なお、セッション開始レスポンスの詳細は、後述する図２３を用いて説明する。

クライアント３は、セッション開始レスポンスを受信すると、セッションＩＤを含むディレクトリサービス４０の利用リクエストを作成し、ディレクトリサービス４０に送信する（図５のシーケンスＳＱ９。）。

なお、ディレクトリサービス利用リクエストの詳細は、後述する図２７を用いて説明する。

ディレクトリサービス４０は、ディレクトリサービス利用リクエストに含まれるセッションＩＤを基に、有効なセッションＩＤかどうかを判定し、有効なセッションＩＤであると判定するとディレクトリサービス利用リクエストに応じて処理を行い、該ディレクトリサービス利用リクエストに対応するディレクトリサービス利用レスポンスを作成し、クライアント３に送信する（図５のシーケンスＳＱ１０。）。

なお、ディレクトリサービス利用レスポンスの詳細は、後述する図２８を用いて説明する。

図５のシーケンスＳＱ６に示すように、本発明における認証サービス提供方法及び／又はＷｅｂサービス提供方法においては、クライアント３からのリクエストに含まれるＷｅｂサービス利用チケットＩＤが有効なＷｅｂサービス利用チケットＩＤかどうかを、Ｗｅｂサービス（例えば、ディレクトリサービス４０）が、認証サービス３０に問い合わせる。

また、図５のシーケンスＳＱ７に示したように、該問い合わせを受けた認証サービス３０は、該Ｗｅｂサービス利用チケットＩＤが有効なＷｅｂサービス利用チケットＩＤかどうかの判定を行い、その結果を要求元のＷｅｂサービス（例えば、ディレクトリサービス４０）に返す。

このような認証の方法にすることによって、例えば、認証サービス３０は、Ｗｅｂサービス提供サーバ２に新たなＷｅｂサービスが追加された場合も、当該認証サービス３０に新たな設定等をする必要なく、認証チケット５０及び／又はＷｅｂサービス利用チケット６０を管理しておくことによって、認証サービス及び／又はＷｅｂサービスを提供することができる。

以下、認証サービス３０の一例の機能構成を、図６を用いて説明する。

図６は、認証サービスの一例の機能構成図である。

図６に示されるように、認証サービス３０は、認証振り分け部３１と、チケット管理部３２と、認証プロバイダＡ３３と、認証プロバイダＢ３４と、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）スタブ３５とを含む。

ＳＯＡＰスタブ３５は、クライアント３及び／又はＷｅｂサービス提供サーバ２との間でＳＯＡＰによる通信を実現するためのモジュールである。

認証振り分け部３１は、クライアント３及び／又はＷｅｂサービス提供サーバ２に対して、各種認証プロバイダに対する共通のインターフェースを提供するモジュールである。認証振り分け部３１は、例えば、プロバイダ名に応じて認証を行う認証プロバイダを呼び出す。

認証プロバイダＡ３３及び認証プロバイダＢ３４等は、「認証プロバイダ」と呼ばれるモジュールである。ここで、認証プロバイダとは、様々な認証エンジンを認証サービス３０に組み込むためのアダプタ、又は仲介者のような役割を果たすものである。なお、認証エンジンとは、ここでは実際にパスワードの照合等の認証処理を行うシステムをいう。

即ち、個々の認証エンジンは、それぞれ独自のインターフェース（プロトコル）を有している。一方、それぞれの認証エンジンにおける認証機能をＷｅｂサービスとしてクライアント３に提供するには認証振り分け部３１との間で規定される所定のインターフェースに従う必要がある。かかる個々の認証エンジンによる独自のプロトコルを吸収し、認証振り分け部３１に対して共通のインターフェースを提供するのが、認証プロバイダである。従って、新たな認証エンジンを認証サービス３０に組み込むには、認証プロバイダを一つ実装することになる。但し、認証プロバイダ自身が、認証エンジンとしての機能を有していてもよい。

チケット管理部３２は、認証に係るチケットを管理するモジュールである。チケット管理部３２は、例えば、認証チケット５０、ユーザ情報、グループ情報、Ｗｅｂサービス利用チケット６０等を管理する。

なお、図６においては、複数の認証プロバイダを有する例を用いて認証サービス３０の機能構成を説明したが、必ずしも複数の認証プロバイダを有する必要は無く、例えば、認証プロバイダＡ３３のみを有する構成であってもよい。なお、このような構成の場合、認証振り分け部３１は、認証サービス３０の構成に必ずしも含まれない。

但し、以下では説明の簡略化のため、認証サービス３０は、図６に示されるように複数の認証プロバイダを有し、また認証振り分け部３１も認証サービス３０に含まれるものとして説明を行う。なお、このことは、本発明の実施を制限するものではない。

以下、ディレクトリサービス４０の一例の機能構成を、図７を用いて説明する。

図７は、ディレクトリサービスの一例の機能構成図である。

図７に示されるように、ディレクトリサービス４０は、ディレクトリ振り分け部４１と、セッション管理部４２と、ディレクトリプロバイダＡ４３と、ディレクトリプロバイダＢ４４と、ＳＯＡＰスタブ４５とを含む。

ＳＯＡＰスタブ４５は、クライアント３及び／又は認証サービス提供サーバ１との間でＳＯＡＰによる通信を実現するためのモジュールである。

ディレクトリ振り分け部４１は、クライアント３及び／又は認証サービス提供サーバ１に対して、各種ディレクトリプロバイダに対する共通のインターフェースを提供するモジュールである。ディレクトリ振り分け部４１は、例えば、プロバイダ名に応じて、ディレクトリプロバイダを呼び出す。

ディレクトリプロバイダＡ４３及びディレクトリプロバイダＢ４４等は、「ディレクトリプロバイダ」と呼ばれるモジュールである。ここで、ディレクトリプロバイダとは、様々なディレクトリエンジンをディレクトリサービス４０に組み込むためのアダプタ、又は仲介者のような役割を果たすものである。なお、ディレクトリエンジンとは、ここでは、例えば、該ディレクトリに係るユーザ情報やグループ情報等の管理及び／又はこれらの情報の提供を行うシステムをいう。

即ち、個々のディレクトリエンジンは、それぞれ独自のインターフェース（プロトコル）を有している。一方、それぞれのディレクトリエンジンにおける機能をＷｅｂサービスとしてクライアント３に提供するには、ディレクトリ振り分け部４１との間で規定される所定のインターフェースに従う必要がある。かかる個々のディレクトリエンジンによる独自のプロトコルを吸収し、ディレクトリ振り分け部４１に対して共通のインターフェースを提供するのが、ディレクトリプロバイダである。従って、新たなディレクトリエンジンをディレクトリサービス４０に組み込むには、ディレクトリプロバイダを一つ実装することになる。但し、ディレクトリプロバイダ自身が、ディレクトリエンジンとしての機能を有していてもよい。

セッション管理部４２は、セッション７０を管理するモジュールである。

なお、図７においては、複数のディレクトリプロバイダを有する例を用いてディレクトリプロバイダ４０の機能構成を説明したが、必ずしも複数のディレクトリプロバイダを有する必要は無く、例えば、ディレクトリプロバイダＡ４３のみを有する構成であってもよい。なお、このような構成の場合、ディレクトリ振り分け部４１は、ディレクトリサービス４０の構成に必ずしも含まれない。

但し、以下では説明の簡略化のため、ディレクトリサービス４０は、図７に示されるように複数のディレクトリプロバイダを有し、またディレクトリ振り分け部４１もディレクトリサービス４０に含まれるものとして説明を行う。なお、このことは、本発明の実施を制限するものではない。

以下、認証チケット取得リクエストの一例を、図８を用いて説明する。

図８は、認証チケット取得リクエストの一例を説明するための図である。

図８に示されるように、認証チケット取得リクエストの＜ｐｒｏｖｉｄｅｒＮａｍｅ＞＜／ｐｒｏｖｉｄｅｒＮａｍｅ＞のタグには、認証プロバイダを識別するプロバイダ名がパラメータとして含まれている。

また、＜ｄｏｍａｉｎＮａｍｅ＞＜／ｄｏｍａｉｎＮａｍｅ＞のタグには、ドメイン名がパラメータとして含まれている。

また、＜ａｕｔｈＮａｍｅ＞＜／ａｕｔｈＮａｍｅ＞のタグには、ユーザ名がパラメータとして含まれている。

また、＜ｐａｓｓｗｏｒｄ＞＜／ｐａｓｓｗｏｒｄ＞のタグには、パスワードがパラメータとして含まれている。

また、＜ｄｕｒａｔｉｏｎ＞＜／ｄｕｒａｔｉｏｎ＞のタグには、認証チケット５０の有効時間が秒数を単位とし、パラメータとして含まれている。

例えば、図８に示されるような認証チケット取得リクエストを受信したＳＯＡＰスタブ３５は、前記各パラメータを引数として、認証サービス３０が提供するメソッドであるａｕｔｈｅｎｔｉｃａｔｅＢｙＰａｓｓｗｏｒｄを呼び出す。

すると認証振り分け部３１は、前記プロバイダ名を基に、対応する認証プロバイダ（例えば、認証プロバイダＡ３３）に、前記ドメイン名、前記ユーザ名、前記パスワード等を渡し、認証を要求する。

認証の要求を受けた認証プロバイダＡ３３は、前記ドメイン名、前記ユーザ名、前記パスワード等を含む該ユーザの認証要求を、例えば、外部の認証サーバ等に送信する。

例えば、正当なユーザである旨の認証結果と、該ユーザが所属するグループ情報とを前記外部の認証サーバ等より受信した認証プロバイダＡ３３は、該受信した情報と、前記パスワード及び前記認証チケット５０の有効時間等をチケット管理部３２に渡し、認証チケット５０の作成を要求する。

前記要求を受け取ったチケット管理部３２は、後述する図１０に示されるような認証チケット５０を作成し、該認証チケット５０を識別する識別情報である認証チケットＩＤを認証チケット５０として認証プロバイダＡ３３に渡す。

認証プロバイダＡ３３は、前記認証チケットＩＤを、認証振り分け部３１に渡す。

認証振り分け部３１は、前記認証チケットＩＤ等を引数とし、認証サービス３０が提供するメソッドであるａｕｔｈｅｎｔｉｃａｔｅＢｙＰａｓｓｗｏｒｄＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ３５は、前記認証チケットＩＤを含む後述する図９に示されるような認証チケット取得レスポンスを作成し、クライアント３に送信する。

以下、認証チケット取得レスポンスの一例を、図９を用いて説明する。

図９は、認証チケット取得レスポンスの一例を説明するための図である。

図９に示されるように、認証チケット取得レスポンスの＜ｒｅｔｕｒｎ ｘｓｉ：ｔｙｐｅ＝"ｘｓｄ：ｂａｓｅ６４Ｂｉｎａｒｙ"＞＜／ｒｅｔｕｒｎ＞のタグには、前記認証チケットＩＤが含まれている。

該認証チケットＩＤを取得したクライアント３は、後述するように、該認証チケットＩＤを含んだＷｅｂサービス利用チケット６０の取得リクエストを作成し、認証サービス３０に送信する。

以下、認証チケット５０の内部構造の一例を、図１０を用いて説明する。

図１０は、認証チケットの内部構造の一例を説明するための図である。

図１０に示されるように、認証チケット５０は、認証チケットＩＤと、プロバイダ名と、有効期限と、ユーザ情報と、グループ情報と、パスワードとを含む。

認証チケットＩＤには、認証チケット５０を識別する識別情報が格納されている。プロバイダ名には、認証を行った認証プロバイダの名前が格納されている。有効期限には、認証を行った認証プロバイダより渡された、当該認証チケット５０の有効期限が格納されている。ユーザ情報には、認証を行った認証プロバイダより渡された、ユーザのユーザ情報の構造体がそのまま格納されている。グループ情報には、認証を行った認証プロバイダより渡された、前記ユーザが所属するグループのグループ情報の構造体へのポインタの配列が格納されている。パスワードには、認証を行った認証プロバイダより渡された、パスワードが格納されている。

以下、ユーザ情報構造体の一例を、図１１を用いて説明する。

図１１は、ユーザ情報構造体の一例を説明するための図である。

図１１に示されるようにユーザ情報構造体は、ユーザＩＤと、ドメイン名と、名前とを含む。

ユーザＩＤには、ユーザを識別する識別情報が格納されている。ドメイン名には、前記ユーザに対応するドメイン名が格納されている。名前には、前記ユーザの名前が格納されている。

なお、ユーザ情報構造体に、姓、名、ニックネーム、表示名、名前の読み、社員番号、住所、電話番号、メールアドレス、役職、所属組織、兼務情報、課金コード、所属グループ、管理者権限の有無等を更に含めるようにしてもよい。

以下、グループ情報構造体の一例を、図１２を用いて説明する。

図１２は、グループ情報構造体の一例を説明するための図である。

図１２に示されるようにグループ情報構造体は、グループＩＤと、ドメイン名と、名前とを含む。

グループＩＤには、前記ユーザが所属するグループを識別する識別情報が格納されている。ドメイン名には、該グループに対応するドメイン名が格納されている。名前には、該グループの名前が格納されている。

なお、グループ情報構造体に、グループ名称、グループ説明文、上位グループ、下位グループ、グループメンバー、グループコード、課金用コード等を更に含めるようにしてもよい。

以下、認証チケット作成処理の一例を、図１３を用いて説明する。

図１３は、認証チケット作成処理の一例を説明するためのフローチャートである。

ステップＳ１０において、ＳＯＡＰスタブ３５は、クライアント３より図８に示される認証チケット取得リクエストを受信する。上述したように、認証チケット取得リクエストを受信したＳＯＡＰスタブ３５は、認証チケット取得リクエストに含まれる各パラメータを引数として、認証サービス３０が提供するメソッドであるａｕｔｈｅｎｔｉｃａｔｅＢｙＰａｓｓｗｏｒｄを呼び出す。

ステップＳ１０に続いてステップＳ１１に進み、認証振り分け部３１は、前記パラメータの一つであるプロバイダ名を基に、該プロバイダ名が有効なプロバイダ名かどうかを判定する。

認証振り分け部３１は、有効なプロバイダ名であると判定すると（ステップＳ１１においてＹＥＳ）、対応する認証プロバイダ（例えば、認証プロバイダＡ３３）にドメイン名、ユーザ名、パスワード等のパラメータを渡し、認証を要求する。

一方、認証振り分け部３１は、有効なプロバイダ名でないと判定すると（ステップＳ１１においてＮＯ）、処理を終了する。

例えば、認証振り分け部３１は、認証プロバイダの名前を保持、管理し、前記パラメータに含まれるプロバイダ名と前記保持、管理している認証プロバイダ名とを比較し、対応する有効なプロバイダ名が存在するかどうかを判定する。

ステップＳ１２において、前記認証の要求を受け取った認証プロバイダＡ３３は、例えば、外部の認証サーバ等にユーザの認証を要求する場合、前記外部の認証サーバが動作中かどうかを判定する。

認証プロバイダＡ３３は、対応する外部の認証サーバが動作中であると判定すると（ステップＳ１２においてＹＥＳ）、該外部の認証サーバに、ドメイン名、ユーザ名、パスワード等を含むユーザの認証要求を送信する。

一方、認証プロバイダＡ３３は、対応する外部の認証サーバが動作していないと判定すると（ステップＳ１２においてＮＯ）、処理を終了する。

例えば、認証プロバイダＡ３３は、対応する外部の認証サーバにｐｉｎｇ（Ｐａｃｋｅｔ Ｉｎｔｅｒｎｅｔ Ｇｒｏｐｅｒ）を打って、前記外部の認証サーバが動作中かどうかを判定する。

ステップＳ１３では、認証プロバイダＡ３３が、認証が成功したかどうかを判定する。

認証プロバイダＡ３３は、認証が成功したと判定すると（ステップＳ１３においてＹＥＳ）、前記外部の認証サーバ等より受信した前記ユーザが所属するグループ情報や、前記認証チケット取得リクエストに含まれていたユーザの情報やパスワード及び認証チケット５０の有効時間等をチケット管理部３２に渡し、認証チケット５０の作成を要求する。

一方、認証プロバイダＡ３３は、認証が失敗したと判定すると（ステップＳ１３においてＮＯ）、処理を終了する。

例えば、認証プロバイダＡ３３は、前記外部の認証サーバより、認証が成功した旨の認証結果と、前記ユーザが所属するグループ情報等を受信すると、認証が成功したと判定する。

ステップＳ１４では、前記認証チケット５０の作成要求を受け取ったチケット管理部３２が、図１０に示されるような認証チケット５０を作成し、該認証チケット５０を識別する識別情報である認証チケットＩＤを認証チケット５０として認証プロバイダＡ３３に渡す。

ステップＳ１４に続いてステップＳ１５に進み、認証プロバイダＡ３３より前記認証チケットＩＤを渡された認証振り分け部３１は、前記認証チケットＩＤ等を引数とし、認証サービス３０が提供するメソッドであるａｕｔｈｅｎｔｉｃａｔｅＢｙＰａｓｓｗｏｒｄＲｅｓｐｏｎｓｅを呼び出す。するとＳＯＡＰスタブ３５は、認証振り分け部３１からの要求に基づいて、図９に示されるような前記認証チケットＩＤを含んだ、認証チケット取得レスポンスを作成する。

ステップＳ１５に続いてステップＳ１６に進み、ＳＯＡＰスタブ３５は、ステップＳ１５において作成した認証チケット取得レスポンスをクライアント３に送信する。

なお、外部の認証サーバ等を用いず、例えば、認証プロバイダＡ３３が、認証エンジンとしての機能する場合、ステップＳ１２に示す処理を行わず、直接認証プロバイダＡ３３自身が認証を行い、認証が成功したかどうか判定するステップＳ１３の処理を行うようにしてもよい。

以下、Ｗｅｂサービス利用チケット取得リクエストの一例を、図１４を用いて説明する。

図１４は、Ｗｅｂサービス利用チケット取得リクエストの一例を説明するための図である。

図１４に示されるように、Ｗｅｂサービス利用チケット取得リクエストの＜ｍａｓｔｅｒＡｕｔｈＴｉｃｋｅｔ＞＜／ｍａｓｔｅｒＡｕｔｈＴｉｃｋｅｔ＞のタグには、認証チケットＩＤがパラメータとして含まれている。

また、＜ｄｕｒａｔｉｏｎ＞＜／ｄｕｒａｔｉｏｎ＞のタグには、Ｗｅｂサービス利用チケット６０の有効時間が秒数を単位とし、パラメータとして含まれている。

また、＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグには、クライアントが利用するＷｅｂサービス（例えば、ディレクトリサービス４０）が要求する該Ｗｅｂサービスを識別する文字列（以下、単にターゲットともいう）がパラメータとして含まれている。

例えば、図１４に示されるようなＷｅｂサービス利用チケット取得リクエストを受信したＳＯＡＰスタブ３５は、前記各パラメータを引数として、認証サービス３０が提供するメソッドであるｃｒｅａｔｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

すると認証振り分け部３１は、前記認証チケットＩＤを基に、該認証チケットＩＤに対応する有効な認証チケット５０が存在するかどうか等を判定する。

認証振り分け部３１は、前記認証チケットＩＤに対応する有効な認証チケット５０がチケット管理部３２に存在すると判定すると、前記認証チケットＩＤに対応する認証チケット５０に含まれるプロバイダ名等をチケット管理部３２より取得し、前記プロバイダ名に対応する認証プロバイダ（例えば、認証プロバイダＡ３３）に、前記認証チケットＩＤ、前記Ｗｅｂサービス利用チケット６０の有効時間、前記ターゲット等を渡す。

認証プロバイダＡ３３は、前記認証チケットＩＤ、前記Ｗｅｂサービス利用チケット６０の有効時間、前記ターゲット等をチケット管理部３２に渡し、Ｗｅｂサービス利用チケット６０の作成を要求する。

前記要求を受け取ったチケット管理部３２は、後述する図１６に示されるようなＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０を識別する識別情報であるＷｅｂサービス利用チケットＩＤをＷｅｂサービス利用チケット６０として認証プロバイダＡ３３に渡す。

なお、図１４に示されるＷｅｂサービス利用チケット取得リクエストの＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに何も含まれていなかった場合、チケット管理部３２は、後述する図１６のターゲットに何も含まない、どのＷｅｂサービスであっても利用可能なＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０を識別する識別情報であるＷｅｂサービス利用チケットＩＤをＷｅｂサービス利用チケット６０として認証プロバイダＡ３３に渡すようにしてもよい。

なお、以下では説明の簡略化のため、Ｗｅｂサービス利用チケット取得リクエストの＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグには、クライアント３が利用するＷｅｂサービス（例えば、ディレクトリサービス４０）が要求する該Ｗｅｂサービスを識別する識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）が含まれているものとして説明を行う。

認証プロバイダＡ３３は、前記Ｗｅｂサービス利用チケットＩＤを、認証振り分け部３１に渡す。

認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤ等を引数とし、認証サービス３０が提供するメソッドであるｃｒｅａｔｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ３５は、前記Ｗｅｂサービス利用チケットＩＤを含む後述する図１５に示されるようなＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する。

以下、Ｗｅｂサービス利用チケット取得レスポンスの一例を、図１５を用いて説明する。

図１５は、Ｗｅｂサービス利用チケット取得レスポンスの一例を説明するための図である。

図１５に示されるように、Ｗｅｂサービス利用チケット取得レスポンスの＜ｒｅｔｕｒｎ ｘｓｉ：ｔｙｐｅ＝"ｘｓｄ：ｂａｓｅ６４Ｂｉｎａｒｙ"＞＜／ｒｅｔｕｒｎ＞のタグには、前記Ｗｅｂサービス利用チケットＩＤが含まれている。

該Ｗｅｂサービス利用チケットＩＤを取得したクライアント３は、後述するように、該Ｗｅｂサービス利用チケットＩＤを含んだセッション開始リクエストをディレクトリサービス４０に送信する。

以下、Ｗｅｂサービス利用チケット６０の内部構造の一例を、図１６を用いて説明する。

図１６は、Ｗｅｂサービス利用チケットの内部構造の一例を説明するための図である。

図１６に示されるように、Ｗｅｂサービス利用チケット６０は、Ｗｅｂサービス利用チケットＩＤと、認証チケットＩＤと、ターゲットと、有効期限とを含む。

Ｗｅｂサービス利用チケットＩＤには、Ｗｅｂサービス利用チケット６０を識別する識別情報が格納されている。認証チケットＩＤには、認証プロバイダ（例えば、認証プロバイダＡ３３）より渡された、認証チケット５０を識別する識別情報が格納されている。ターゲットには、認証プロバイダ（例えば、認証プロバイダＡ３３）より渡された、Ｗｅｂサービスを識別する文字列が格納されている。有効期限には、認証プロバイダ（例えば、認証プロバイダＡ３３）より渡された、当該Ｗｅｂサービス利用チケット６０の有効期限が格納されている。

なお、認証チケットＩＤの替わりに、図１０に示した認証チケット５０の内容がそのままＷｅｂサービス利用チケット６０に含まれていてもよい。

以下、チケット管理部３２内のデータの概念図を、図１７を用いて説明する。

図１７は、チケット管理部内のデータの概念図である。

図１７に示されるように、図１０において説明した認証チケット５０に対して図１１において説明したユーザ情報は１対１に対応付けられている。

また、認証チケット５０に対して図１２において説明したグループ情報は１対ｎ（但し、ｎは０以上の自然数）に対応付けられている。これは、認証されたユーザがどのグループにも所属していない場合もあれば、複数のグループに所属している場合もあるからである。

また、認証チケット５０に対して図１６において説明したＷｅｂサービス利用チケット６０は、１対ｍ（但し、ｍは１以上の自然数）に対応付けられている。これは、例えば、Ｗｅｂサービス提供サーバ２が提供するＷｅｂサービスが複数存在するためである。

以下、Ｗｅｂサービス利用チケット作成処理の一例を、図１８を用いて説明する。

図１８は、Ｗｅｂサービス利用チケット作成処理の一例を説明するためのフローチャートである。

ステップＳ２０において、ＳＯＡＰスタブ３５は、クライアント３より図１４に示されるＷｅｂサービス利用チケット取得リクエストを受信する。上述したように、Ｗｅｂサービス利用チケット取得リクエストを受信したＳＯＡＰスタブ３５は、Ｗｅｂサービス利用チケット取得リクエストに含まれる各パラメータを引数として、認証サービス３０が提供するメソッドであるｃｒｅａｔｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

ステップＳ２０に続いてステップＳ２１に進み、認証振り分け部３１は、前記パラメータの一つである認証チケットＩＤを基に、該認証チケットＩＤに対応する認証チケット５０が存在するかどうかを判定する。

認証振り分け部３１は、前記認証チケットＩＤに対応する認証チケット５０が存在すると判定すると（ステップＳ２１においてＹＥＳ）、ステップＳ２４に進み、前記認証チケットＩＤに対応する認証チケット５０が存在しないと判定すると（ステップＳ２１においてＮＯ）、ステップＳ２２に進む。

例えば、認証振り分け部３１は、前記認証チケットＩＤを含む、該認証チケットＩＤに対応する認証チケット５０が存在するかどうかの問い合わせをチケット管理部３２に行い、対応する認証チケット５０が存在する旨の応答がチケット管理部３２よりあった場合、前記認証チケットＩＤに対応する認証チケット５０が存在すると判定する。

一方、前記認証チケットＩＤに対応する認証チケット５０が存在しない旨の応答をチケット管理部３２より受け取ると、認証振り分け部３１は、前記認証チケットＩＤに対応する認証チケット５０が存在しないと判定する。

ステップＳ２２において、認証振り分け部３１は、認証サービス３０が提供する所定のメソッドを呼び出して、対応する認証チケット５０が存在しない旨のエラーメッセージの作成を要求する。ＳＯＡＰスタブ３５は、前記要求に応じて、対応する認証チケット５０が存在しない旨のエラーメッセージを作成する。

ステップＳ２２に続いてステップＳ２３に進み、ＳＯＡＰスタブ３５は、ステップＳ２２において作成したエラーメッセージをクライアント３に送信し、処理を終了する。

一方、ステップＳ２４では、認証振り分け部３１が、前記認証チケットＩＤを基に、該認証チケットＩＤに対応する認証チケット５０の有効期限が切れていないかどうかを判定する。

認証振り分け部３１は、前記認証チケットＩＤに対応する認証チケット５０の有効期限が切れていないと判定すると（ステップＳ２４においてＹＥＳ）、前記認証チケットＩＤを基に、チケット管理部３２より、前記認証チケットＩＤに対応する認証チケット５０に含まれるプロバイダ名を取得し、該プロバイダ名に対応する認証プロバイダ（例えば、認証プロバイダＡ３３）に対して、前記認証チケットＩＤ、前記Ｗｅｂサービス利用チケット６０の有効時間、前記ターゲット等を渡す。

認証プロバイダＡ３３は、前記認証チケットＩＤ、前記Ｗｅｂサービス利用チケット６０の有効時間、前記ターゲット等をチケット管理部３２に渡し、Ｗｅｂサービス利用チケット６０の作成を要求し、ステップＳ２７に進む。

一方、認証振り分け部３１は、前記認証チケットＩＤに対応する認証チケット５０の有効期限が切れていると判定すると（ステップＳ２４においてＮＯ）、ステップＳ２５に進む。

例えば、認証振り分け部３１は、前記認証チケットＩＤを含む、該認証チケットＩＤに対応する認証チケット５０の有効期限が切れていないかどうかの問い合わせをチケット管理部３２に行い、対応する認証チケット５０の有効期限が切れていない旨の応答がチケット管理部３２よりあった場合、前記認証チケットＩＤに対応する認証チケット５０の有効期限が切れていないと判定する。

一方、前記認証チケットＩＤに対応する認証チケット５０の有効期限が切れている旨の応答をチケット管理部３２より受け取ると、認証振り分け部３１は、前記認証チケットＩＤに対応する認証チケット５０の有効期限が切れていると判定する。

ステップＳ２５において、認証振り分け部３１は、認証サービス３０が提供する所定のメソッドを呼び出して、対応する認証チケット５０の有効期限が切れている旨のエラーメッセージの作成を要求する。ＳＯＡＰスタブ３５は、前記要求に応じて、対応する認証チケット５０の有効期限が切れている旨のエラーメッセージを作成する。

ステップＳ２５に続いてステップＳ２６に進み、ＳＯＡＰスタブ３５は、ステップＳ２５において作成したエラーメッセージをクライアント３に送信し、処理を終了する。

一方、ステップＳ２７では、前記Ｗｅｂサービス利用チケット６０の作成要求を受け取ったチケット管理部３２が、図１６に示されるようなＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０を識別する識別情報であるＷｅｂサービス利用チケットＩＤをＷｅｂサービス利用チケット６０として認証プロバイダＡ３３に渡す。

ステップＳ２７に続いてステップＳ２８に進み、認証プロバイダＡ３３より前記Ｗｅｂサービス利用チケットＩＤを渡された認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤを引数とし、認証サービス３０が提供するメソッドであるｃｒｅａｔｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。するとＳＯＡＰスタブ３５は、認証振り分け部３１からの要求に基づいて、図１５に示されるような前記Ｗｅｂサービス利用チケットＩＤを含んだＷｅｂサービス利用チケット取得レスポンスを作成する。

ステップＳ２８に続いてステップＳ２９に進み、ＳＯＡＰスタブ３５は、認証振り分け部３１からの要求に基づいて、ステップＳ２８において作成したＷｅｂサービス利用チケット取得レスポンスをクライアント３に送信する。

なお、図１８に示すように、認証サービス３０は、認証チケット５０が存在しない旨のエラーメッセージと、認証チケット５０の有効期限が切れている旨のエラーメッセージとを分けてクライアント３に送信している。

例えば、クライアント３が、一度ユーザによって入力されたパスワード等を保持している場合、クライアント３は、認証サービス３０より認証チケット５０の有効期限が切れている旨のエラーメッセージを受信すると、前記パスワードを用いて、認証チケット５０の取得リクエストを再び認証サービス３０に送信することができる。

なお、認証サービス３０は、当該認証サービス３０が提供する削除メソッドが呼ばれるか、又はある定められた期間（例えば、認証チケット５０が作成されてから１時間）経過すると、対応する認証チケット５０を削除する。

以下、セッション開始リクエストの一例を、図１９を用いて説明する。

図１９は、セッション開始リクエストの一例を説明するための図である。

図１９に示されるように、セッション開始リクエストの＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグには、Ｗｅｂサービス利用チケットＩＤがパラメータとして含まれている。

また、＜ｔｉｍｅＬｉｍｉｔ＞＜／ｔｉｍｅＬｉｍｉｔ＞のタグには、セッション７０の有効時間が秒数を単位とし、パラメータとして含まれている。

例えば、図１９に示されるようなセッション開始リクエストを受信したＳＯＡＰスタブ４５は、前記各パラメータを引数として、ディレクトリサービス４０が提供するメソッドであるｓｔａｒｔＳｅｓｓｉｏｎＢｙＡｕｔｈＴｉｃｋｅｔを呼び出す。

するとディレクトリ振り分け部４１は、前記Ｗｅｂサービス利用チケットＩＤ及び当該ディレクトリサービス４０が提供するサービスを識別する文字列を引数とし、ディレクトリサービス４０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

するとＳＯＡＰスタブ４５は、前記Ｗｅｂサービス利用チケットＩＤ及び当該ディレクトリサービス４０が提供するサービスを識別する文字列を含む後述する図２１に示されるようなＷｅｂサービス利用チケット解読リクエストを作成し、認証サービス３０に送信する。

なお、送信先の認証サービス３０に係る情報（例えば、ＵＲＬ等）は、ディレクトリ振り分け部４１がＨＤＤ２９等より取得し、メソッドｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔの引数としてＳＯＡＰスタブ４５に提供してもよいし、クライアント３が、セッション開始リクエストに、Ｗｅｂサービス利用チケット解読リクエストの送信先である認証サービス３０のＵＲＬ等を含めてディレクトリサービス４０に送信し、該認証サービス３０のＵＲＬをディレクトリ振り分け部４１がメソッドｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔの引数としてＳＯＡＰスタブ４５に提供するようにしてもよい。

以下、セッション開始リクエストの他の例を、図２０を用いて説明する。

図２０は、セッション開始リクエストの他の例を説明するための図である。

図２０に示されるセッション開始リクエストには、＜ｕａｕｔｈｅｎｔｉｃａｔｉｏｎＵｒｌ＞＜／ｕａｕｔｈｅｎｔｉｃａｔｉｏｎＵｒｌ＞のタグに、認証サービス３０のＵＲＬがパラメータとして含まれている。

ディレクトリサービス４０は、該認証サービス３０のＵＲＬを基に、後述する図２１に示されるようなＷｅｂサービス利用チケット解読リクエストを認証サービス３０に送信する。

また、図示しないが、クライアント３は、図１９及び／又は図２０に示されるセッション開始リクエストに、ディレクトリプロバイダのプロバイダ名を含めて、ディレクトリサービス４０に送信するようにしてもよい。このような構成にすることによって、クライアント３は、ディレクトリプロバイダを指定することができる。

以下、Ｗｅｂサービス利用チケット解読リクエストの一例を、図２１を用いて説明する。

図２１は、Ｗｅｂサービス利用チケット解読リクエストの一例を説明するための図である。

図２１に示されるように、Ｗｅｂサービス利用チケット解読リクエストの＜ａｕｔｈＴｉｃｋｅｔ＞＜／ａｕｔｈＴｉｃｋｅｔ＞のタグには、Ｗｅｂサービス利用チケットＩＤがパラメータとして含まれている。

また、＜ｔａｒｇｅｔ＞＜／ｔａｒｇｅｔ＞のタグには、ディレクトリサービス４０が提供するサービスを識別する文字列が含まれている。

例えば、図２１に示されるようなＷｅｂサービス利用チケット解読リクエストを受信したＳＯＡＰスタブ３５は、前記各パラメータを引数として、認証サービス３０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

すると認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤ及び／又は前記ディレクトリサービス４０が提供するサービスを識別する文字列を用い、前記Ｗｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在するかどうか及び該Ｗｅｂサービス利用チケット６０に含まれるターゲットと、前記ディレクトリサービス４０が提供するサービスを識別する文字列とが同じかどうか等を判定する。

認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在し、且つ該Ｗｅｂサービス利用チケット６０に含まれるターゲットと、前記ディレクトリサービス４０が提供するサービスを識別する文字列とが同じであると判定すると、例えば、対応するＷｅｂサービス利用チケット６０に含まれる認証チケットＩＤを基に、図１０に示されるような認証チケット５０の内容（但し、認証チケットＩＤ以外）及び／又は図１６に示されるようなＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）を取得し、これらの情報及び後述する判定結果等を引数とし、認証サービス３０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ３５は、例えば、前記判定結果や、認証チケット５０の内容及び／又はＷｅｂサービス利用チケット６０の内容等を含むＷｅｂサービス利用チケット解読レスポンスを作成し、ディレクトリサービス４０に送信する。

以下、Ｗｅｂサービス利用チケット解読レスポンスの一例を、図２２を用いて説明する。

図２２は、Ｗｅｂサービス利用チケット解読レスポンスの一例を説明するための図である。

図２２に示されるように、Ｗｅｂサービス利用チケット解読レスポンスの＜ｒｅｔｕｒｎ ｘｓｉ：ｔｙｐｅ＝"ｘｓｄ：ｓｔｒｉｎｇ"＞＜／ｒｅｔｕｒｎ＞のタグには、判定結果が含まれている。

なお、判定結果としては、例えば、前記Ｗｅｂサービス利用チケット解読リクエストに含まれるＷｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在し、且つ該Ｗｅｂサービス利用チケット６０に含まれるターゲットが、前記Ｗｅｂサービス利用チケット解読リクエストに含まれるディレクトリサービス４０が提供するサービスを識別する文字列と同じであった場合は、ＯＫが前記タグに含まれる。

一方、例えば、前記Ｗｅｂサービス利用チケット解読リクエストに含まれるＷｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在しなかったり、前記Ｗｅｂサービス利用チケット６０に含まれるターゲットが、前記Ｗｅｂサービス利用チケット解読リクエストに含まれるディレクトリサービス４０が提供するサービスを識別する文字列と同じでなかったりした場合は、ＮＯが前記タグに含まれる。

なお、上述したように、Ｗｅｂサービス利用チケット解読レスポンスには、認証チケット５０の内容（但し、認証チケットＩＤ以外）及び／又はＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）等を含めるようにしてもよい。

図２２に示されるようなＷｅｂサービス利用チケット解読レスポンスを受信したＳＯＡＰスタブ４５は、例えば、該Ｗｅｂサービス利用チケット解読レスポンスに含まれるプロバイダ名を基に、対応するディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）に、前記Ｗｅｂサービス利用チケットＩＤ及び前記セッション７０の有効時間等を渡す。

なお、上述したように、セッション開始リクエストに、ディレクトリプロバイダのプロバイダ名が含まれていた場合は、該プロバイダ名を基の、対応するディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）に、前記Ｗｅｂサービス利用チケットＩＤ及び前記セッション７０の有効時間等を渡してもよい。

ディレクトリプロバイダＡ４３は、前記Ｗｅｂサービス利用チケットＩＤ及び前記セッション７０の有効時間等をセッション管理部４２に渡し、セッション７０の作成を要求する。

前記要求を受け取ったセッション管理部４２は、後述する図２４に示されるようなセッション７０を作成し、該セッション７０を識別する識別情報であるセッションＩＤをセッション７０としてディレクトリプロバイダＡ４３に渡す。

ディレクトリプロバイダＡ４３は、前記セッションＩＤをディレクトリ振り分け部４１に渡す。

ディレクトリ振り分け部４１は、前記セッションＩＤ等を引数とし、ディレクトリサービス４０が提供するメソッドであるｓｔａｒｔＳｅｓｓｉｏｎＢｙＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ４５は、前記セッションＩＤを含む後述する図２３に示されるようなセッション開始レスポンスを作成し、クライアント３に送信する。

以下、セッション開始レスポンスの一例を、図２３を用いて説明する。

図２３は、セッション開始レスポンスの一例を説明するための図である。

図２３に示されるように、セッション開始レスポンスの＜ｒｅｔｕｒｎＶａｌｕｅ ｘｓｉ：ｔｙｐｅ＝"ｘｓｄ：ｓｔｒｉｎｇ"＞＜／ｒｅｔｕｒｎＶａｌｕｅ＞のタグには、前記セッションＩＤが含まれている。

該セッションＩＤを取得したクライアント３は、例えば、後述するように、該セッションＩＤを含んだディレクトリサービス利用リクエストをディレクトリサービス４０に送信する。

以下、セッション７０の内部構造の一例を、図２４を用いて説明する。

図２４は、セッションの内部構造の一例を説明するための図である。

図２４に示されるように、セッション７０は、セッションＩＤと、Ｗｅｂサービス利用チケットＩＤと、有効期限とを含む。

セッションＩＤには、セッション７０を識別する識別情報が格納されている。Ｗｅｂサービス利用チケットＩＤには、ディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）より渡された、Ｗｅｂサービス利用チケット６０を識別する識別情報が格納されている。有効期限には、ディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）より渡された、セッション７０の有効期限が格納されている。

以下、セッション作成処理の一例を、図２５を用いて説明する。

図２５は、セッション作成処理の一例を説明するためのフローチャートである。

ステップＳ３０において、ＳＯＡＰスタブ４５は、クライアント３より図１９に示されるようなセッション開始リクエストを受信する。上述したように、セッション開始リクエストを受信したＳＯＡＰスタブ４５は、セッション開始リクエストに含まれるＷｅｂサービス利用チケットＩＤや、セッション７０の有効時間等のパラメータを引数として、ディレクトリサービス４０が提供するメソッドであるｓｔａｒｔＳｅｓｓｉｏｎＢｙＡｕｔｈＴｉｃｋｅｔを呼び出す。

するとディレクトリ振り分け部４１は、前記Ｗｅｂサービス利用チケットＩＤ及び当該ディレクトリサービス４０が提供するサービスを識別する文字列を引数とし、ディレクトリサービス４０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

ステップＳ３０に続いてステップＳ３１に進み、ＳＯＡＰスタブ４５は、前記Ｗｅｂサービス利用チケットＩＤ及び当該ディレクトリサービス４０が提供するサービスを識別する文字列を含む図２１に示されるようなＷｅｂサービス利用チケット解読リクエストを作成し、認証サービス３０に送信する。

ステップＳ３１に続いてステップＳ３２に進み、ＳＯＡＰスタブ４５は、認証サービス３０より図２２に示されるようなＷｅｂサービス利用チケット解読レスポンスを受信する。上述したように、Ｗｅｂサービス利用チケット解読レスポンスを受信したＳＯＡＰスタブ４５は、Ｗｅｂサービス利用チケット解読レスポンスに含まれる解読結果（以下、判定結果ともいう）や、認証チケット５０の内容（但し、認証チケットＩＤ以外）及び／又はＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）等を引数とし、ディレクトリサービス４０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

ステップＳ３２に続いてステップＳ３３に進み、ディレクトリ振り分け部４１は、ステップＳ３１においてＷｅｂサービス利用チケット解読リクエストに含めて認証サービス３０に送信したＷｅｂサービス利用チケットＩＤが、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤであったかどうかを判定する。

ディレクトリ振り分け部４１は、前記Ｗｅｂサービス利用チケットＩＤが、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤであったと判定すると（ステップＳ３３においてＹＥＳ）、例えば、該Ｗｅｂサービス利用チケット解読レスポンスに含まれるプロバイダ名を基に、対応するディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）に、前記Ｗｅｂサービス利用チケットＩＤ及び前記セッション７０の有効時間等を渡す。

ディレクトリプロバイダＡ４３は、前記Ｗｅｂサービス利用チケットＩＤ及び前記セッション７０の有効時間等をセッション管理部４２に渡し、セッション７０の作成を要求し、ステップＳ３４に進む。

一方、ディレクトリ振り分け部４１は、前記Ｗｅｂサービス利用チケットＩＤが、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤでなかったと判定すると（ステップＳ３３においてＮＯ）、処理を終了する。

なお、ディレクトリ振り分け部４１が、前記Ｗｅｂサービス利用チケットＩＤは、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤでなかったと判定した場合、ディレクトリサービス４０が提供する所定のメソッドを呼び出して、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤでなかった旨のエラーメッセージを作成し、クライアント３に送信するようにしてもよい。

例えば、ディレクトリ振り分け部４１は、ステップＳ３２において受信したＷｅｂサービス利用チケット解読レスポンスに、ＯＫのパラメータが含まれていた場合、有効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤであったと判定し、Ｗｅｂサービス利用チケット解読レスポンスに、ＮＯのパラメータが含まれていた場合、無効なＷｅｂサービス利用チケット６０のＷｅｂサービス利用チケットＩＤであったと判定する。

ステップＳ３４において、セッション管理部４２は、図２４に示されるようなセッション７０を作成し、該セッション７０を識別する識別情報であるセッションＩＤをセッション７０としてディレクトリプロバイダＡ４３に渡す。

ステップＳ３４に続いてステップＳ３５に進み、ディレクトリプロバイダＡ４３より前記セッションＩＤを渡されたディレクトリ振り分け部４１は、前記セッションＩＤ等を引数とし、ｓｔａｒｔＳｅｓｓｉｏｎＢｙＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。するとＳＯＡＰスタブ４５は、ディレクトリ振り分け部４１からの要求に基づいて、図２３に示されるようなセッションＩＤを含んだセッション開始レスポンスを作成する。

ステップＳ３５に続いてステップＳ３６に進み、ＳＯＡＰスタブ４５は、ディレクトリ振り分け部４１からの要求に基づいて、ステップＳ３５において作成したセッション開始レスポンスをクライアント３に送信する。

以下、Ｗｅｂサービス利用チケット解読処理の一例を、図２６を用いて説明する。

図２６は、Ｗｅｂサービス利用チケット解読処理の一例を説明するためのフローチャートである。

ステップＳ４０において、ＳＯＡＰスタブ３５は、ディレクトリサービス４０より、図２１に示されるようなＷｅｂサービス利用チケット解読リクエストを受信する。上述したように、Ｗｅｂサービス利用チケット解読リクエストを受信したＳＯＡＰスタブ３５は、Ｗｅｂサービス利用チケット解読リクエストに含まれるＷｅｂサービス利用チケットＩＤやディレクトリサービス４０が提供するサービスを識別する文字列等のパラメータを引数として、認証サービス３０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔを呼び出す。

ステップＳ４０に続いてステップＳ４１に進み、認証振り分け部３１は、前記パラメータの一つであるＷｅｂサービス利用チケットＩＤを基に、該Ｗｅｂサービス利用チケットＩＤが正しいものかどうかを判定する。

認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤが正しいと判定すると（ステップＳ４１においてＹＥＳ）、ステップＳ４２に進み、前記Ｗｅｂサービス利用チケットＩＤが正しくないと判定すると（ステップＳ４１においてＮＯ）、ステップＳ４５に進む。

例えば、認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤを含む、該Ｗｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在するかどうかの問い合わせをチケット管理部３２に行い、対応する有効なＷｅｂサービス利用チケット６０が存在する旨の応答がチケット管理部３２よりあった場合、正しいＷｅｂサービス利用チケットＩＤであると判定する。

一方、前記Ｗｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在しない旨の応答をチケット管理部３２より受け取ると、認証振り分け部３１は、正しくないＷｅｂサービス利用チケットＩＤであると判定する。

ステップＳ４２では、認証振り分け部３１が、前記パラメータの一つであるディレクトリサービス４０が提供するサービスを識別する文字列と、前記Ｗｅｂサービス利用チケットＩＤに対応するサービス利用チケット６０に含まれるターゲットの文字列とが一致するかどうかを判定する。

認証振り分け部３１は、前記二つの文字列が一致すると判定すると（ステップＳ４２においてＹＥＳ）、ステップＳ４３に進み、前記二つの文字列が一致しないと判定すると（ステップＳ４２においてＮＯ）、ステップＳ４５に進む。

ステップＳ４３では、認証振り分け部３１が、前記Ｗｅｂサービス利用チケットＩＤを基に、対応するＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）及び／又は認証チケット５０の内容（但し、認証チケットＩＤ以外）を取得し、これらの情報と共に、判定結果（ＹＥＳ）等を引数とし、認証サービス３０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ３５は、例えば、前記判定結果（ＹＥＳ）や、認証チケット５０の内容及び／又はＷｅｂサービス利用チケット６０の内容等を含むＷｅｂサービス利用チケット解読レスポンスを作成する。

ステップＳ４３に続いてステップＳ４４に進み、ＳＯＡＰスタブ３５は、ステップＳ４３において作成したＷｅｂサービス利用チケット解読レスポンスをディレクトリサービス４０に送信する。

一方、ステップＳ４５では、認証振り分け部３１が、判定結果（ＮＯ）等を引数とし、認証サービス３０が提供するメソッドであるｄｅｃｏｄｅＡｕｔｈＴｉｃｋｅｔＲｅｓｐｏｎｓｅを呼び出す。

するとＳＯＡＰスタブ３５は、例えば、前記判定結果（ＮＯ）等を含むＷｅｂサービス利用チケット解読レスポンスを作成する。

ステップＳ４５に続いてステップＳ４６に進み、ＳＯＡＰスタブ３５は、ステップＳ４５において作成したＷｅｂサービス利用チケット解読レスポンスをディレクトリサービス４０に送信する。

図２５及び図２６に示したように、ディレクトリサービス４０は、クライアント３からのリクエストに含まれるＷｅｂサービス利用チケットＩＤと共に、当該自身の識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）を認証サービス３０に送信する。一方、認証サービス３０は、前記Ｗｅｂサービス利用チケットＩＤを基に、ディレクトリサービス４０から送信された識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）と、Ｗｅｂサービス利用チケット６０に含まれるターゲットとを比較することによって、Ｗｅｂサービス利用チケット６０の有効性を判定する。

このような認証方法を取ることによって、クライアント３が利用し、且つ認証を必要とするＷｅｂサービスが、例えばＷｅｂサービス提供サーバ２等に新たに追加された場合も、認証サービス提供サーバ１及び／又は認証サービス３０に新たな情報等を設定することなく、効率的に認証に係るサービスを提供することができる。

なお、図２６のステップＳ４３では、認証振り分け部３１が、前記Ｗｅｂサービス利用チケットＩＤを基に、対応するＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）及び／又は認証チケット５０の内容（但し、認証チケットＩＤ以外）を取得するよう説明を行ったが、認証振り分け部３１は、前記Ｗｅｂサービス利用チケットＩＤを基に、対応するプロバイダ名のみをチケット管理部３２より取得し、該プロバイダ名に対応するプロバイダ（例えば、認証プロバイダＡ３３）に、前記Ｗｅｂサービス利用チケットＩＤに対応するＷｅｂサービス利用チケット６０の内容及び／又は認証チケット５０の内容を取得するよう要求するようにしてもよい。

この場合、該要求を受け取った認証プロバイダＡ３３は、該要求をチケット管理部３２に渡す。該要求を受け取ったチケット管理部３２は、該要求に含まれるＷｅｂサービス利用チケットＩＤを基に、対応するＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）及び／又は認証チケット５０の内容（但し、認証チケットＩＤ以外）を取得し、認証プロバイダＡ３３に渡す。認証プロバイダＡ３３は、取得したＷｅｂサービス利用チケット６０の内容（但し、Ｗｅｂサービス利用チケットＩＤ及び認証チケットＩＤ以外）及び／又は認証チケット５０の内容（但し、認証チケットＩＤ以外）を認証振り分け部３１に渡す。

以下、ディレクトリサービス利用リクエストの一例を、図２７を用いて説明する。

図２７は、ディレクトリサービス利用リクエストの一例を説明するための図である。

図２７に示されるように、ディレクトリサービス利用リクエストの＜ｓｅｓｓｉｏｎＩｄ＞＜／ｓｅｓｓｉｏｎＩｄ＞のタグには、セッションＩＤがパラメータとして含まれている。

ディレクトリサービス４０は、ディレクトリサービス利用リクエストに含まれるセッションＩＤが有効なセッションＩＤかどうかを判定し、有効なセッションＩＤであると判定すると、クライアント３の要求に応じて、ユーザ一覧を取得し、後述する図２８に示されるようなディレクトリサービス利用レスポンスを作成し、クライアント３に送信する。

以下、ディレクトリサービス利用レスポンスの一例を、図２８を用いて説明する。

図２８は、ディレクトリサービス利用レスポンスの一例を説明するための図である。

図２８に示されるディレクトリサービス利用レスポンスの＜ｉｔｅｍ＞＜／ｉｔｅｍ＞のタグに含まれる各タグには、ユーザ一覧に係る情報が含まれている。

以下、ユーザ一覧取得処理の一例を、図２９を用いて説明する。

図２９は、ユーザ一覧取得処理の一例のフローチャートである。

ステップＳ５０において、ＳＯＡＰスタブ４５は、クライアント３より図２７に示されるようなディレクトリサービス利用リクエストを受信する。ディレクトリサービス利用リクエストを受信したＳＯＡＰスタブ４５は、ディレクトリサービス利用リクエストに含まれる各パラメータを引数として、ディレクトリサービス４０が提供するメソッドであるｇｅｔＥｎｔｒｙＬｉｓｔを呼び出す。

ステップＳ５０に続いてステップＳ５１に進み、ディレクトリ振り分け部４１は、前記ディレクトリサービス利用リクエストに含まれていたパラメータの一つであるセッションＩＤが有効なセッションＩＤかどうかを判定する。

ディレクトリ振り分け部４１は、有効なセッションＩＤであると判定すると（ステップＳ５１においてＹＥＳ）、ステップＳ５２に進み、有効なセッションＩＤでないと判定すると（ステップＳ５２においてＮＯ）、処理を終了する。

なお、ディレクトリ振り分け部４１が、有効なセッションＩＤでないと判定した場合、該旨のエラーメッセージを作成し、クライアント３に送信するようにしてもよい。

例えば、ディレクトリ振り分け部４１は、ディレクトリサービス利用リクエストに含まれるセッションＩＤを用いて、前記セッションＩＤに対応するセッションＩＤを含むセッション７０が存在するかどうか、及び／又は対応するセッションＩＤを含むセッション７０の有効期限が切れていないかどうかの問い合わせをセッション管理部４２に対して行い、対応するセッションＩＤが存在する及び／又は対応するセッションＩＤを含むセッション７０の有効期限が切れていない旨の応答をセッション管理部４２により取得すると、有効なセッションＩＤであると判定する。

ステップＳ５２では、例えば、対応するディレクトリプロバイダ（例えば、ディレクトリプロバイダＡ４３）が、ユーザ一覧を取得する。

ステップＳ５２に続いてステップＳ５３では、ディレクトリプロバイダＡ４３より前記ユーザ一覧を渡されたディレクトリ振り分け部４１は、前記ユーザ一覧を引数とし、ディレクトリサービス４０が提供するメソッドであるｇｅｔＥｎｔｒｙＬｉｓｔＲｅｓｐｏｎｓｅを呼び出す。するとＳＯＡＰスタブ４５は、ディレクトリ振り分け部４１からの要求に基づいて、図２８に示されるような前記ユーザ一覧を含んだ、ディレクトリサービス利用レスポンスを作成する。

ステップＳ５３に続いてステップＳ５４に進み、ＳＯＡＰスタブ４５は、ステップＳ５３において作成したディレクトリサービス利用レスポンスをクライアント３に送信する。

以下、認証サービス提供方法及び／又はＷｅｂサービス提供方法の他の例を、図３０を用いて説明する。

例えば、図５において説明した認証サービス提供方法及び／又はＷｅｂサービス提供方法では、クライアント３が、Ｗｅｂサービス（例えば、ディレクトリサービス４０）を利用する場合に、どの認証サービスに認証を要求すれば良いのか、該認証サービスのＵＲＬや、ディレクトリサービス４０を利用する際に必要となるディレクトリサービス４０を識別する識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）を知っている場合を例に取って説明を行った。

以下に示す図３０においては、最初にクライアント３が、ディレクトリサービス４０を利用する場合に必要となる対応する認証サービスのＵＲＬ及びディレクトリサービス４０を識別する識別情報等をディレクトリサービス４０に問い合わせる例を用いて説明を行う。

図３０は、認証サービス提供方法及び／又はＷｅｂサービス提供方法を説明するためのシーケンス図（その２）である。

図３０に示されるように、Ｗｅｂサービス提供サーバ２が提供するＷｅｂサービス（例えば、ディレクトリサービス４０）を利用するクライアント３は、認証を行う認証サービスに係る情報（例えば、認証サービスのＵＲＬ等）及び／又はディレクトリサービス４０を利用するときに必要となる当該ディレクトリサービス４０を識別する識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）の取得リクエスト（情報取得リクエスト）をディレクトリサービス４０に送信する（図３０のシーケンスＳＱ２０。）。

ディレクトリサービス４０は、クライアント３からの前記情報取得リクエストに応じて、当該ディレクトリサービス４０を利用するときに必要となる認証に係るサービスを提供する認証サービス３０のＵＲＬ及び／又は当該ディレクトリサービス４０を利用するときに必要となる当該ディレクトリサービス４０を識別するｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列を含む情報取得レスポンスを作成し、クライアント３に送信する（図３０のシーケンスＳＱ２１。）。

このような構成の場合、ディレクトリサービス４０は、当該ディレクトリサービス４０を利用するときに必要となる認証に係るサービスを提供する認証サービス３０のＵＲＬ及び／又は当該ディレクトリサービス４０を利用するときに必要となる当該ディレクトリサービス４０を識別するｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列を保持し、管理する。

前記情報取得レスポンスを受信したクライアント３は、該取得レスポンスに含まれる認証サービス３０のＵＲＬを基に、クライアント３のユーザを認証する認証チケット５０の取得リクエストを作成し、認証サービス３０に送信する（図３０のシーケンスＳＱ２２。）。

認証サービス３０は、クライアント３からの認証チケット取得リクエストに含まれるユーザ名、パスワード等を基に認証を行い、認証チケット５０を作成し、該認証チケット５０のＩＤ（認証チケットＩＤ）を含む認証チケット取得レスポンスを作成し、クライアント３に送信する（図３０のシーケンスＳＱ２３。）。

クライアント３は、認証チケット取得レスポンスを受信すると、前記認証チケットＩＤ及びシーケンスＳＱ２１においてディレクトリサービス４０より取得したディレクトリサービス４０を識別するｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列を含む、Ｗｅｂサービス利用チケット６０の取得リクエストを、認証サービス３０に送信する（図３０のシーケンスＳＱ２４。）。

図３０のシーケンスＳＱ２５からシーケンスＳＱ３１までの処理は、図５のシーケンスＳＱ４からシーケンスＳＱ１０までの処理と同様である。

図３０に示したように、Ｗｅｂサービス（例えば、ディレクトリサービス４０）が、認証サービス３０に係る情報（例えば、認証サービスのＵＲＬ等）及び／又は当該ディレクトリサービス４０を識別する識別情報（例えば、ｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列）を保持、管理することによって、クライアント３は、認証サービス３０のＵＲＬ及び／又はディレクトリサービス４０を識別するｒｅｐｏｓｉｔｏｒｙＳｅｒｖｉｃｅ等の文字列を知らなくても、ディレクトリサービス４０等に問い合わせることによって、前記情報を取得することができる。

更に図３０に示した処理の１つ前段階の処理として、例えば、クライアント３が、利用したいＷｅｂサービス（例えば、ディレクトリサービス４０）のＵＲＬ等を知らない場合、Ｗｅｂサービス等の検索を行うディスカバリサービス等にディレクトリサービス４０のＵＲＬの検索要求を送信し、ディスカバリサービスより取得したディレクトリサービス４０のＵＲＬを用いて、図３０に示したシーケンスＳＱ２０のように、ディレクトリサービス４０に情報取得リクエストを送信するようにしてもよい。

このような構成の場合、クライアント３は、利用したいＷｅｂサービス（例えば、ディレクトリサービス４０）のＵＲＬ等を知らなくても、ディスカバリサービスを用い、ディレクトリサービス４０等のＵＲＬを取得し、図３０に示したような処理を行うことができる。

このようなディスカバリサービスは、例えば、認証サービス提供サーバ１に実装されていても良いし、Ｗｅｂサービス提供サーバ２に実装されていても良い。また、他のサーバ等に実装されていても良いし、認証サービス３０及びディレクトリサービス４０等と同じサーバ（装置）等に実装されていてもよい。

実施例２では、認証サービス３０以外のＷｅｂサービスが複数（例えば２つ）存在する場合について説明を行う。なお、実施例２では、実施例１とは異なる点について主に説明を行う。

図３１は、複数のＷｅｂサービスが存在した場合の認証サービス提供方法及び／又はＷｅｂサービス提供方法の一例を説明するためのシーケンス図である。

図３１に示されるように、例えばターゲットＡＢＣで識別されるＷｅｂサービス８０（以下、Ｗｅｂサービス（ターゲットＡＢＣ）８０ともいう）が提供するサービスを利用するクライアント３は、クライアント３のユーザを認証する認証チケット５０の取得リクエストを作成し、認証サービス３０に送信する（図３１のシーケンスＳＱ５０。）。

認証サービス３０は、クライアント３からの認証チケット取得リクエストに含まれるユーザ名、パスワード等を基に認証を行い、認証チケット５０を作成し、該認証チケット５０のＩＤ（認証チケットＩＤ）を含む認証チケット取得レスポンスを作成し、クライアント３に送信する（図３１のシーケンスＳＱ５１。）。

クライアント３は、認証チケット取得レスポンスを受信すると、前記認証チケットＩＤと、利用したいＷｅｂサービス（ターゲットＡＢＣ）８０が要求する該Ｗｅｂサービスを識別する識別情報（図３１の例においては、ＡＢＣ）と、を含む、Ｗｅｂサービス（ターゲットＡＢＣ）８０の利用を許可するＷｅｂサービス利用チケット６０の取得リクエストを作成し、認証サービス３０に送信する（図３１のシーケンスＳＱ５２。）。

なお、ここで、クライアント３は、例えばＷｅｂサービス（ターゲットＡＢＣ）８０に問い合わせを行い、事前に、Ｗｅｂサービス（ターゲットＡＢＣ）８０が要求する該Ｗｅｂサービスを識別する識別情報がＡＢＣであることを取得しているものとする。

認証サービス３０は、Ｗｅｂサービス利用チケット取得リクエストに含まれる認証チケットＩＤを基に、対応する有効な認証チケット５０が存在するかどうか等を判定し、対応する有効な認証チケット５０が存在すると判定すると、前記Ｗｅｂサービス利用チケット取得リクエストに含まれるＷｅｂサービスを識別する識別情報（図３１の例においては、ＡＢＣ）を含むＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０のＩＤ（Ｗｅｂサービス利用チケットＩＤ）を含むＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する（図３１のシーケンスＳＱ５３。）。

クライアント３は、Ｗｅｂサービス利用チケット取得レスポンスを受信すると、前記Ｗｅｂサービス利用チケットＩＤを含む、Ｗｅｂサービス（ターゲットＡＢＣ）８０が提供するサービスの利用リクエストを作成し、Ｗｅｂサービス（ターゲットＡＢＣ）８０に送信する（図３１のシーケンスＳＱ５４。）。

なお、クライアント３は、実施例１で説明したように、Ｗｅｂサービスに、セッション開始リクエストを送信し、Ｗｅｂサービスとのセッションが確立した後に、セッションＩＤ等を含むサービス利用リクエストをＷｅｂサービスに送信してもよい。しかし、図３１に示されるように、セッションを確立せずに、直接Ｗｅｂサービス利用チケットＩＤを含むサービスの利用リクエストをＷｅｂサービスに送信するようにしてもよい。以下においても同様である。また、このことは、実施例１でも同様である。

Ｗｅｂサービス（ターゲットＡＢＣ）８０は、サービスの利用リクエストに含まれるＷｅｂサービス利用チケットＩＤを基に、該Ｗｅｂサービス利用チケットＩＤと当該Ｗｅｂサービス（ターゲットＡＢＣ）８０を識別する識別情報（図３１の例においては、ＡＢＣ）とを含むＷｅｂサービス利用チケット６０の解読リクエストを作成し、認証サービス３０に送信する（図３１のシーケンスＳＱ５５。）。

認証サービス３０は、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるＷｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在し、且つ該Ｗｅｂサービス利用チケット６０に含まれる識別情報（図３１の例においては、ＡＢＣ）と、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるＷｅｂサービス（ターゲットＡＢＣ）８０を識別する識別情報（図３１の例においては、ＡＢＣ）とが同じであると判定すると、例えば、判定結果（図３１の例においては、ＯＫ）や、認証チケット５０の内容及び／又はＷｅｂサービス利用チケット６０の内容等を含むＷｅｂサービス利用チケット解読レスポンスを作成し、Ｗｅｂサービス（ターゲットＡＢＣ）８０に送信する（図３１のシーケンスＳＱ５６。）。

Ｗｅｂサービス（ターゲットＡＢＣ）８０は、Ｗｅｂサービス利用チケット解読レスポンスに含まれる判定結果（図３１の例においては、ＯＫ）を基に、シーケンスＳＱ５４において受信したサービスの利用リクエストに応じた処理を実行し、サービス利用レスポンスを作成し、クライアント３に送信する（図３１のシーケンスＳＱ５７。）。

ここで、例えばＷｅｂサービス（ターゲットＡＢＣ）８０が悪意のあるＷｅｂサービスであって、シーケンスＳＱ５４において受信したサービスの利用リクエストに含まれる、Ｗｅｂサービス（ターゲットＡＢＣ）８０の利用を許可するＷｅｂサービス利用チケットＩＤを用いて、例えばターゲットＤＥＦで識別されるＷｅｂサービス９０（以下、Ｗｅｂサービス（ターゲットＤＥＦ）９０ともいう）が提供するサービスを利用しようとした場合の処理をシーケンスＳＱ５８からシーケンスＳＱ６１を用いて説明する。

Ｗｅｂサービス（ターゲットＡＢＣ）８０は、シーケンスＳＱ５４において受信したサービスの利用リクエストに含まれるＷｅｂサービス利用チケットＩＤを含む、Ｗｅｂサービス（ターゲットＤＥＦ）９０が提供するサービスの利用リクエストを、Ｗｅｂサービス（ターゲットＤＥＦ）９０に送信する（図３１のシーケンスＳＱ５８。）。

Ｗｅｂサービス（ターゲットＤＥＦ）９０は、サービスの利用リクエストに含まれるＷｅｂサービス利用チケットＩＤを基に、該Ｗｅｂサービス利用チケットＩＤと当該Ｗｅｂサービス（ターゲットＤＥＦ）９０を識別する識別情報（図３１の例においては、ＤＥＦ）とを含むＷｅｂサービス利用チケット６０の解読リクエストを作成し、認証サービス３０に送信する（図３１のシーケンスＳＱ５９。）。

認証サービス３０は、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるＷｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在するが、該Ｗｅｂサービス利用チケット６０に含まれる識別情報（図３１の例においては、ＡＢＣ）と、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるＷｅｂサービス（ターゲットＤＥＦ）９０を識別する識別情報（図３１の例においては、ＤＥＦ）とが異なると判定すると、判定結果（図３１の例においては、ＮＧ）を含むＷｅｂサービス利用チケット解読レスポンスを作成し、Ｗｅｂサービス（ターゲットＤＥＦ）９０に送信する（図３１のシーケンスＳＱ６０。）。

Ｗｅｂサービス（ターゲットＤＥＦ）９０は、Ｗｅｂサービス利用チケット解読レスポンスに含まれる判定結果（図３１の例においては、ＮＧ）を基に、解読が失敗した旨のエラー情報を含むサービス利用レスポンス作成し、Ｗｅｂサービス（ターゲットＡＢＣ）８０に送信する（図３１のシーケンスＳＱ６１。）。

図３１に示したように、本発明に係る認証サービス提供方法及び／又はＷｅｂサービス提供方法では、例えばＷｅｂサービス（ターゲットＡＢＣ）８０が悪意のあるＷｅｂサービスであって、当該自身の利用を許可するＷｅｂサービス利用チケットＩＤを用いて、Ｗｅｂサービス（ターゲットＤＥＦ）９０が提供するサービスを利用しようとしても、ターゲット（識別情報）が異なるため、使用することができない。したがって、例えば通信経路上においてチケット又はチケットＩＤ等を盗まれても他のＷｅｂサービスを利用することはできない。

また、上述したように、本発明に係る認証サービス提供方法及び／又はＷｅｂサービス提供方法では、新しいＷｅｂサービスをシステムに追加した場合であっても、認証サービス３０やクライアント３の設定を変更する必要がない。

なお、図３１に示されるＷｅｂサービス（ターゲットＡＢＣ）８０と、Ｗｅｂサービス（ターゲットＤＥＦ）９０と、は同じＷｅｂサービス提供サーバ２に実装されていてもよいし、異なるＷｅｂサービス提供サーバ２にそれぞれ実装されていてもよい。

実施例３では、Ｗｅｂサービス利用チケット６０の作成を要求し、取得したサービス以外のサービスが、該Ｗｅｂサービス利用チケット６０（又はＷｅｂサービス利用チケットＩＤ）を使用する一例について説明を行う。なお、実施例３では、実施例１及び実施例２とは異なる点について主に説明を行う。

図３２は、他のＷｅｂサービスがＷｅｂサービス利用チケットを利用する場合の認証サービス提供方法及び／又はＷｅｂサービス提供方法の一例を説明するためのシーケンス図である。

図３２に示されるように、例えばターゲットＡＢＣで識別されるディレクトリサービス４０において管理されている文書の印刷を行いたいクライアント３は、クライアント３のユーザを認証する認証チケット５０の取得リクエストを作成し、認証サービス３０に送信する（図３２のシーケンスＳＱ８０。）。

認証サービス３０は、クライアント３からの認証チケット取得リクエストに含まれるユーザ名、パスワード等を基に認証を行い、認証チケット５０を作成し、該認証チケット５０のＩＤ（認証チケットＩＤ）を含む認証チケット取得レスポンスを作成し、クライアント３に送信する（図３２のシーケンスＳＱ８１。）。

クライアント３は、認証チケット取得レスポンスを受信すると、前記認証チケットＩＤと、文書の管理を行っているディレクトリサービス４０が要求する該ディレクトリサービス４０を識別する識別情報（図３２の例においては、ＡＢＣ）と、を含む、ディレクトリサービス４０の取得リクエストを作成し、認証サービス３０に送信する（図３２のシーケンスＳＱ８２。）。

認証サービス３０は、Ｗｅｂサービス利用チケット取得リクエストに含まれる認証チケットＩＤを基に、対応する有効な認証チケット５０が存在するかどうか等を判定し、対応する有効な認証チケット５０が存在すると判定すると、前記Ｗｅｂサービス利用チケット取得リクエストに含まれるＷｅｂサービスを識別する識別情報（図３２の例においては、ＡＢＣ）を含むＷｅｂサービス利用チケット６０を作成し、該Ｗｅｂサービス利用チケット６０のＩＤ（Ｗｅｂサービス利用チケットＩＤ）を含むＷｅｂサービス利用チケット取得レスポンスを作成し、クライアント３に送信する（図３２のシーケンスＳＱ８３。）。

クライアント３は、Ｗｅｂサービス利用チケット取得レスポンスを受信すると、前記Ｗｅｂサービス利用チケットＩＤと、印刷したい文書を識別する文書識別情報とを含む、印刷リクエストを作成し、印刷に係るサービスを提供する印刷サービス１００に送信する（図３２のシーケンスＳＱ８４。）。

印刷サービス１００は、印刷リクエストを受信すると、該印刷リクエストに含まれるＷｅｂサービス利用チケットＩＤと、文書識別情報とを含む文書アクセスリクエストを作成し、ディレクトリサービス４０に送信する（図３２のシーケンスＳＱ８５。）。

ディレクトリサービス４０は、文書アクセスリクエストを受信すると、該文書アクセスリクエストに含まれるＷｅｂサービス利用チケットＩＤと、当該ディレクトリサービス４０を識別する識別情報（図３２の例においては、ＡＢＣ）とを含むＷｅｂサービス利用チケット６０の解読リクエストを作成し、認証サービス３０に送信する（図３２のシーケンスＳＱ８６。）。

認証サービス３０は、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるＷｅｂサービス利用チケットＩＤに対応する有効なＷｅｂサービス利用チケット６０が存在し、且つ該Ｗｅｂサービス利用チケット６０に含まれる識別情報（図３１の例においては、ＡＢＣ）と、Ｗｅｂサービス利用チケット６０の解読リクエストに含まれるディレクトリサービス４０を識別する識別情報（図３２の例においては、ＡＢＣ）とが同じであると判定すると、例えば、判定結果（図３２の例においては、ＯＫ）や、認証チケット５０の内容及び／又はＷｅｂサービス利用チケット６０の内容等を含むＷｅｂサービス利用チケット解読レスポンスを作成し、ディレクトリサービス４０に送信する（図３２のシーケンスＳＱ８７。）。

ディレクトリサービス４０は、Ｗｅｂサービス利用チケット解読レスポンスを受信すると、該Ｗｅｂサービス利用チケット解読レスポンスに含まれる判定結果（図３２の例においては、ＯＫ）を基に、文書識別情報に対応する文書（又は文書内容）を取得し、該文書（又は文書内容）を含む文書アクセスレスポンスを作成し、印刷サービス１００に送信する（図３２のシーケンスＳＱ８８。）。

印刷サービス１００は、文書アクセスレスポンスを受信すると、該文書アクセスレスポンスに含まれる文書（又は文書内容）に基づいて、印刷を行い、印刷結果等を含む印刷レスポンスを作成し、クライアント３に送信する（図３２のシーケンスＳＱ８９。）。

図３２に示したように、Ｗｅｂサービス利用チケット６０の作成を要求し、取得したサービス以外のサービスが、該Ｗｅｂサービス利用チケット６０（又はＷｅｂサービス利用チケットＩＤ）を使用することもできる。

以下、認証サービス３０及び／又はディレクトリサービス４０が実装された装置の他の例として、画像を形成する画像形成装置（以下、融合機という）を図３３及び図３４を用いて説明する。

図３３は、融合機の機能構成を示すブロック図である。

図３３において、融合機１２００は、プロッタ１２０１と、スキャナ１２０２と、ファクシミリ等のハードウェアリソース１２０３等を有すると共に、プラットフォーム１２２０とアプリケーション１２３０とから構成されるソフトウェア群１２１０と、融合機起動部１２４０とを備えている。

融合機起動部１２４０は、融合機１２００の電源投入時に先ず始めに実行され、プラットフォーム１２２０やアプリケーション１２３０を起動する。

プラットフォーム１２２０は、アプリケーション１２３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービス１２５０と、一又は複数のハードウェア資源の管理をおこない、コントロールサービス１２５０からの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（Ｓｙｓｔｅｍ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ）１２２３）と、ＯＳ１２２１とを有する。

このコントロールサービス１２５０は、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（Ｓｙｓｔｅｍ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）１２２２と、ＥＣＳ（Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ)１２２４と、ＭＣＳ（Ｍｅｍｏｒｙ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）１２２５と、ＯＣＳ（Ｏｐｅｒａｔｉｏｎ ｐａｎｅｌ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）１２２６と、ＦＣＳ（ＦＡＸ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）１２２７と、ＮＣＳ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）１２２８と、ＩＭＨ（Ｉｍａｇｉｎｇ Ｍｅｍｏｒｙ Ｈａｎｄｌｅｒ）１２２９とがある。なお、このプラットフォーム１２２０は、あらかじめ定義された関数により前記アプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。

ＯＳ１２２１は、ＵＮＩＸ（登録商標）等のオペレーティング・システムであり、プラットフォーム１２２０並びにアプリケーション１２３０の各ソフトウェアをそれぞれプロセスとして並列実行する。

ＳＲＭ１２２３は、ＳＣＳ１２２２と共にシステムの制御及びリソースの管理を行うものであり、スキャナやプロッタ等のエンジン部、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆ等）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。

ＳＣＳ１２２２は、アプリ管理、操作部制御、システム画面表示（ジョブリスト画面、カウンタ表示画面等）、ＬＥＤ表示、リソース管理、割り込みアプリ制御等の複数の機能を行なう。

ＥＣＳ１２２４は、プロッタ１２０１と、スキャナ１２０２と、その他ハードウェアリソース１２０３等のエンジン部を制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリ等を行う。

ＭＣＳ１２２５は、メモリ制御を行うものであり、より具体的には、画像メモリの取得及び開放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮及び伸張等を行う。

ＯＣＳ１２２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理等を行う。

ＦＣＳ１２２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇａｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供する。

ＮＣＳ１２２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行ったりする。

なお、例えば、ＮＣＳ１２２８で、複数のプロトコルのうちｈｔｔｐｄ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｅｍｏｎ）２００によって、インターネットを介して接続されるネットワーク機器とのデータ通信をＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）で制御し、ＨＴＴＰリクエストヘッダで指定されるＷｅｂサービスに対応する処理部を関数コールによって起動し、そのＷｅｂサービスによる処理結果をＨＴＴＰレスポンスで該ネットワーク機器へ通知するように構成しても良い。Ｗｅｂサービスは、例えば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述されたメッセージに従って提供される。

ＩＭＨ１２２９は、イメージデータを仮想メモリ領域（ユーザ仮想空間）から物理メモリへマップする。プロセスの起動に応じて、システムコールを行ない、プロセス用の仮想メモリ領域をマップしたり、マップした仮想メモリ領域をプロセスの終了時に開放したりする処理等を行なう。

アプリケーション１２３０は、ページ記述言語（ＰＤＬ）、ＰＣＬ及びポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１２１１と、コピー用アプリケーションであるコピーアプリ１２１２と、ファクシミリ用アプリケーションであるファックスアプリ１２１３と、スキャナ用アプリケーションであるスキャナアプリ１２１４と、ＷｅｂサービスアプリケーションであるＷｅｂサービス処理アプリ１２１５を有する。なお、ＮＣＳ１２２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加又は削除することができる。

Ｗｅｂサービス処理アプリ１２１５は、Ｗｅｂサービスを要求するＨＴＴＰリクエストを受信して、ＨＴＴＰレスポンスを送信することによってＷｅｂサービスを提供するＷｅｂサーバ５００と、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇａｒａｍ Ｉｎｔｅｒｆａｃｅ）を介してコントロールサービス１２５０を利用して所定処理を行い、その処理結果をＷＳ−ＡＰＩ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇａｒａｍ Ｉｎｔｅｒｆａｃｅ）を介してＷｅｂサービスとして提供するＷｅｂサービスファンクション（ＷＳＦ）１４００とを有する。

本実施例においてＷｅｂサービスファンクション１４００に、認証サービス３０及び／又はディレクトリサービス４０等が実装される。

また、認証チケット５０、ユーザ情報、グループ情報、Ｗｅｂサービス利用チケット６０及び／又はセッション７０等は、後述するＨＤＤ１３０３に格納される。

図３４は、融合機のハードウェア構成を示すブロック図である。

図３４に示すように、この融合機１２００は、オペレーションパネル１３１０、ＦＡＸコントロールユニット（ＦＣＵ）１５３０、エンジン部１３５０（スキャナ１２０２等が接続される）及びプロッタ１２０１とコントローラ１３００のＡＳＩＣ１３０１とをＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ ＣｏｍＰｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス１３０９等で接続した構成となる。

コントローラ１３００は、ＡＳＩＣ１３０１にＭＥＭ−Ｃ１３０２、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１３０３などを接続すると共に、このＡＳＩＣ１３０１とＣＰＵ１３０４とをＣＰＵチップセットのＮＢ１３０５を介して接続している。

ここで、このＡＳＩＣ１３０１とＮＢ１３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ１３０８を介して接続されている。

ＣＰＵ１３０４は、融合機１２００の全体制御を行うものであり、より具体的には、ＯＳ１２２１上でプラットフォーム１２２０を形成するＳＣＳ１２２２、ＳＲＭ１２２３、ＥＣＳ１２２４、ＭＣＳ１２２５、ＯＣＳ１２２６、ＦＣＳ１２２７、ＮＣＳ１２２８をそれぞれプロセスとして起動して実行させると共に、アプリケーション１２３０を形成するプリンタアプリ１２１１、コピーアプリ１２１２、ファックスアプリ１２１３、スキャナアプリ１２１４、Ｗｅｂサービス処理アプリ１２１５を起動して実行させる。

ＮＢ１３０５は、ＣＰＵ１３０４とＭＥＭＰ１３０６、ＳＢ１３０７、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１３４１、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）１３３０、ＩＥＥＥ１３９４１３４０、セントロニクス１３４２、ドライバＩ／Ｆ１３４３、ＡＳＩＣ１３０１とを接続するためのブリッジである。

ＭＥＭＰ１３０６は、融合機の描画用メモリなどとして用いるシステムメモリであり、ＳＢ１３０７は、ＮＢ１３０５とＲＯＭＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＭＥＭ−Ｃ１３０２は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＡＳＩＣ１３０１は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。

ドライバＩ／Ｆ１３４３は、挿入された、プログラム又はアプリケーション等が格納されている記録媒体から、プログラム又はアプリケーション等を読み込んで、融合機１２００に搭載するのに用いるＩ／Ｆである。なお、例えば記録媒体としては、ＳＤメモリカード、スマートメディア、マルチメディアカード、コンパクトフラッシュ（登録商標）等がある。

ＨＤＤ１３０３は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積、文書の蓄積を行うストレージであり、また、本実施例における認証チケット５０、ユーザ情報、グループ情報、Ｗｅｂサービス利用チケット６０及び／又はセッション７０等を格納する。オペレーションパネル１３１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示を行う操作部である。

ＡＳＩＣ１３０１には、ＭＥＭ−Ｃ１３０２を接続するためのＲＡＭインターフェースと、ＨＤＤ１３０３を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力を行う場合には、入出力先がＲＡＭインターフェース又はハードディスクインターフェースに切り替えられる。

ＡＧＰ１３０８は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にする。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

第三者機関による認証の基本概念を説明するための図である。 第三者機関による安全な認証の基本概念を説明するための図である。 認証サービス提供サーバの一例のハードウェア構成図である。 Ｗｅｂサービス提供サーバの一例のハードウェア構成図である。 認証サービス提供方法及び／又はＷｅｂサービス提供方法を説明するためのシーケンス図（その１）である。 認証サービスの一例の機能構成図である。 ディレクトリサービスの一例の機能構成図である。 認証チケット取得リクエストの一例を説明するための図である。 認証チケット取得レスポンスの一例を説明するための図である。 認証チケットの内部構造の一例を説明するための図である。 ユーザ情報構造体の一例を説明するための図である。 グループ情報構造体の一例を説明するための図である。 認証チケット作成処理の一例を説明するためのフローチャートである。 Ｗｅｂサービス利用チケット取得リクエストの一例を説明するための図である。 Ｗｅｂサービス利用チケット取得レスポンスの一例を説明するための図である。 Ｗｅｂサービス利用チケットの内部構造の一例を説明するための図である。 チケット管理部内のデータの概念図である。 Ｗｅｂサービス利用チケット作成処理の一例を説明するためのフローチャートである。 セッション開始リクエストの一例を説明するための図である。 セッション開始リクエストの他の例を説明するための図である。 Ｗｅｂサービス利用チケット解読リクエストの一例を説明するための図である。 Ｗｅｂサービス利用チケット解読レスポンスの一例を説明するための図である。 セッション開始レスポンスの一例を説明するための図である。 セッションの内部構造の一例を説明するための図である。 セッション作成処理の一例を説明するためのフローチャートである。 Ｗｅｂサービス利用チケット解読処理の一例を説明するためのフローチャートである。 ディレクトリサービス利用リクエストの一例を説明するための図である。 ディレクトリサービス利用レスポンスの一例を説明するための図である。 ユーザ一覧取得処理の一例のフローチャートである。 認証サービス提供方法及び／又はＷｅｂサービス提供方法を説明するためのシーケンス図（その２）である。 複数のＷｅｂサービスが存在した場合の認証サービス提供方法及び／又はＷｅｂサービス提供方法の一例を説明するためのシーケンス図である。 他のＷｅｂサービスがＷｅｂサービス利用チケットを利用する場合の認証サービス提供方法及び／又はＷｅｂサービス提供方法の一例を説明するためのシーケンス図である。 融合機の機能構成を示すブロック図である。 融合機のハードウェア構成を示すブロック図である。

符号の説明

１ 認証サービス提供サーバ
２ Ｗｅｂサービス提供サーバ
３ クライアント
１１、２１ 入力装置
１２、２２ 表示装置
１３、２３ ドライブ装置
１４、２４ 記録媒体
１５、２５ ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）
１６、２６ ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）
１７、２７ ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
１８、２８ インターフェース装置
１９、２９ ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）
３０ 認証サービス
３１ 認証振り分け部
３２ チケット管理部
３３ 認証プロバイダＡ
３４ 認証プロバイダＢ
３５ ＳＯＡＰスタブ
４０ ディレクトリサービス
４１ ディレクトリ振り分け部
４２ セッション管理部
４３ ディレクトリプロバイダＡ
４４ ディレクトリプロバイダＢ
４５ ＳＯＡＰスタブ
５０ 認証チケット
６０ Ｗｅｂサービス利用チケット
７０ セッション
８０ Ｗｅｂサービス（ターゲットＡＢＣ）
９０ Ｗｅｂサービス（ターゲットＤＥＦ）
１００ 印刷サービス
２００ ｈｔｔｐｄ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｅｍｏｎ）
１２００ 融合機
１２０１ プロッタ
１２０２ スキャナ
１２０３ その他ハードウェアリソース
１２１０ ソフトウェア群
１２１１ プリンタアプリ
１２１２ コピーアプリ
１２１３ ファックスアプリ
１２１４ スキャナアプリ
１２１５ Ｗｅｂサービス処理アプリ
１２２０ プラットフォーム
１２２１ ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）
１２２２ ＳＣＳ（Ｓｙｓｔｅｍ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）
１２２３ ＳＲＭ（Ｓｙｓｔｅｍ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ）
１２２４ ＥＣＳ（Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ)
１２２５ ＭＣＳ（Ｍｅｍｏｒｙ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）
１２２６ ＯＣＳ（Ｏｐｅｒａｔｉｏｎ ｐａｎｅｌ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）
１２２７ ＦＣＳ（ＦＡＸ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）
１２２８ ＮＣＳ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ）
１２２９ ＩＭＨ（Ｉｍａｇｉｎｇ Ｍｅｍｏｒｙ Ｈａｎｄｌｅｒ）
１２３０ アプリケーション
１３０１ ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）
１３０２ ＭＥＭ−Ｃ
１３０３ ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）
１３０４ ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
１３０５ ＮＢ（ノースブリッジ）
１３０６ ＭＥＭＰ（システムメモリ）
１３０７ ＳＢ（サウスブリッジ）
１３０８ ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）
１３０９ ＰＣＩ Ｂｕｓ（Ｐｅｒｉｐｈｅｒａｌ ＣｏｍＰｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｂｕｓ）
１３１０ オペレーションパネル
１３３０ ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）
１３４０ ＩＥＥＥ１３９４
１３４１ ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）
１３４２ セントロニクス
１３５０ エンジン部
１４００ ＷＳＦ（Ｗｅｂサービスファンクション）
１５３０ ＦＣＵ（ＦＡＸコントロールユニット）

Claims (8)

1. プリンタとスキャナの少なくとも一つを含むハードウエアリソースと、オペレーティングシステムと、前記オペレーティングシステムで動作可能であり画像形成処理に関係するサービスを提供する複数のアプリケーションプログラムと、前記オペレーティングシステムで動作可能であり前記複数のアプリケーションプログラムの一つから処理要求を受信し該受信した処理要求に基づきハードウエアリソースを制御するコントロールプログラムと、を有する画像形成装置であって、
   クライアントから、Ｗｅｂサービス提供装置により提供され、該クライアントが利用するＷｅｂサービスを識別するためのＷｅｂサービス識別子とともに、該Ｗｅｂサービスの利用の許可に係るＷｅｂサービス利用許可情報取得の要求を取得する取得部と、
   前記要求に応じて、前記Ｗｅｂサービス利用許可情報を作成するＷｅｂサービス利用許可情報作成部と、
   作成した該Ｗｅｂサービス利用許可情報と、該Ｗｅｂサービス利用許可情報により利用を許可するＷｅｂサービスの前記Ｗｅｂサービス識別情報とを関連付けて管理する管理部と、
   前記Ｗｅｂサービス提供装置から、該Ｗｅｂサービス提供装置の提供するＷｅｂサービスのＷｅｂサービス識別情報を含むＷｅｂサービス利用許可情報の解読要求を受信する解読要求受信部と、
   前記解読要求に応じて、該Ｗｅｂサービス利用許可情報を解読する解読部とを有し、
   前記解読部は、前記Ｗｅｂサービス提供装置からのＷｅｂサービス利用許可情報に含まれるＷｅｂサービス識別情報と、前記管理段階において前記Ｗｅｂサービス利用許可情報と関連付けて管理されているＷｅｂサービス識別情報とを比較して、有効なＷｅｂサービス利用許可情報であるか否かを判定する判定部を含むこと、
   を特徴とする画像形成装置。
2. 前記Ｗｅｂサービス利用許可情報を識別する識別情報を、前記Ｗｅｂサービス利用許可情報として前記クライアントに送信するＷｅｂサービス利用許可情報送信部を更に有することを特徴とする請求項１記載の画像形成装置。
3. 前記解読部において解読した解読結果を含む前記Ｗｅｂサービス利用許可情報の解読応答を、前記Ｗｅｂサービス提供装置に送信する解読応答送信部を更に有することを特徴とする請求項１又は２記載の画像形成装置。
4. クライアントからの要求に応じて、ユーザの認証に係るユーザ認証情報を作成するユーザ認証情報作成部を更に有することを特徴とする請求項１乃至３何れか一項記載の画像形成装置。
5. 前記ユーザ認証情報を識別する識別情報を、前記ユーザ認証情報として前記クライアントに送信するユーザ認証情報送信部を更に有することを特徴とする請求項４記載の画像形成装置。
6. 前記管理部は、前記ユーザ認証情報を更に管理することを特徴とする請求項４又は５記載の画像形成装置。
7. 前記Ｗｅｂサービス利用許可情報作成部は、クライアントからの要求に含まれる前記ユーザ認証情報に基づいて、前記Ｗｅｂサービス利用許可情報を作成することを特徴とする請求項４乃至６何れか一項記載の画像形成装置。
8. 前記Ｗｅｂサービス利用許可情報作成部は、前記ユーザ認証情報が有効な間、クライアントからの要求に含まれる同一の前記ユーザ認証情報に基づいて、対応するＷｅｂサービスの利用の許可に係るＷｅｂサービス利用許可情報を作成することを特徴とする請求項７記載の画像形成装置。
   

Images