(57)【要約】【課題】クライアントがＷｅｂサービスを利用する際の認証方式が異なる場合に、異なる認証方式を併用して通信を行うことができる認証情報処理装置を提供する。【解決手段】通信対象のＷｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録手段と、クライアントからリクエストメッセージを受信した場合に、受信したリクエストメッセージの内容を分析して、２つの認証方式のいずれであるかを判定し、２つのＷＳＤＬ文書から該当する認証方式のＷＳＤＬ文書を選択する選択手段と、選択手段によって選択したＷＳＤＬ文書に従って、受信したリクエストメッセージから認証情報を抽出し、Ｗｅｂサービスでサポートしている認証方式に合わせて、抽出した認証情報をＷｅｂサービスに対して受け渡すことによりＷｅｂサービスとクライアントとの通信を行なわせる通信制御手段とを備えた。【選択図】図４
2010092407.tif 000002
【特許請求の範囲】
【請求項１】
通信対象のＷｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録手段と、
クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択手段と、
前記選択手段によって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡すことにより前記Ｗｅｂサービスと前記クライアントとの通信を行なわせる通信制御手段と
を備えたことを特徴とする認証情報処理装置。
【請求項２】
前記通信は、ＳＯＡＰを用いた通信であることを特徴とする請求項１に記載の認証情報処理装置。
【請求項３】
前記２つの異なる認証方式は、前記認証情報がＳＯＡＰヘッダに含まれるＳＯＡＰヘッダ方式と、前記認証情報がＳＯＡＰボディに含まれるＳＯＡＰボディ方式のいずれかであることを特徴とする請求項２に記載の認証情報処理装置。
【請求項４】
通信対象のＷｅｂサービスとクライアントとの間で認証情報の伝達を行うための認証情報処理装置における認証情報伝達方法であって、
前記認証情報処理装置が、前記Ｗｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録ステップと、
前記認証情報処理装置が、前記クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択ステップと、
前記認証情報処理装置が、前記選択ステップによって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから前記認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡すことにより前記Ｗｅｂサービスと前記クライアントとの通信を行なわせる通信制御ステップと
を有することを特徴とする認証情報伝達方法。
【請求項５】
前記通信は、ＳＯＡＰを用いた通信であることを特徴とする請求項４に記載の認証情報伝達方法。
【請求項６】
前記２つの異なる認証方式は、前記認証情報がＳＯＡＰヘッダに含まれるＳＯＡＰヘッダ方式と、前記認証情報がＳＯＡＰボディに含まれるＳＯＡＰボディ方式のいずれかであることを特徴とする請求項５に記載の認証情報伝達方法。
【請求項７】
通信対象のＷｅｂサービスとクライアントとの間で認証情報の伝達を行うことにより認証を行う認証方法であって、
前記認証情報処理装置が、前記Ｗｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録ステップと、
前記認証情報処理装置が、前記クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択ステップと、
前記認証情報処理装置が、前記選択ステップによって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから前記認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡す認証情報受け渡しステップと、
前記Ｗｅｂサービスが、認証情報受け渡しステップによって受け渡された前記認証情報によって、前記クライアントの認証を行う認証ステップと
を有することを特徴とする認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービス等のサービスコンポーネントを連携して利用するシステムにおいて、クライアントがＷｅｂサービスを利用する際の認証方式が異なる場合に、異なる認証方式を併用してサービスコンポーネントや端末装置等の認証認可などの共通処理を行う認証情報処理装置、認証情報伝達方法及び認証方法に関する。
【背景技術】
【０００２】
現在ネットワーク上での新たなサービス形態として複数のＷｅｂサービスを連携させたサービスが提案されている。このような連携サービスを実施する上で認証・認可処理やトラヒック制御処理、ユーザ毎のサービス利用回数制限を始めとするＳＬＡ（Service Level Agreement）処理等の共通系処理をネットワーク側で実施することにより、連携サービスを構築する際の利用者あるいはサービスコンポーネント提供者の手間を減らすことができ、ユーザの加入およびサービス提供環境の構築を促進することが可能となる。
【０００３】
共通実行制御機能の関連技術として、ＯＭＡ（Open Mobile Alliance）のＰｏｌｉｃｙ  Ｅｎｆｏｒｃｅｒ（例えば、非特許文献１）では、権限のないリクエストからリソースを保護し、適切なＣｈａｒｇｉｎｇやロギング、プライバシー、施行の実施を管理するポリシーベースの管理メカニズムを提供している。また、このようなネットワーク内部で共通処理を実施する機能として、Ｗｅｂ系サービスとテレコム系サービスの連携を促進する実行制御機能が提案されている（例えば、非特許文献２）。
【０００４】
非特許文献１のＰｏｌｉｃｙ  Ｅｎｆｏｒｃｅｒや実行制御機能では、ポリシーを評価するための認証情報については述べられているが、クライアントとＰｏｌｉｃｙ  Ｅｎｆｏｒｃｅｒ間での認証を行う際に、どのような形式（具体的なインターフェース仕様や言語仕様）で認証情報をやり取りするのかは規定されていないため、現状においては認証方式の実装については自由に行われている。特に、ＳＯＡＰ（Simple Object Access Protocol）  Ｗｅｂサービス利用時の認証情報の渡し方として実装されている方式として、図１に示す２つの方式が用いられている。
【０００５】
第１の方式は、ＳＯＡＰヘッダ内に認証情報を含める方式である。これは、Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｓｅｃｕｒｉｔｙ等の標準に従い、ＳＯＡＰヘッダに認証トークン（Username Token）を格納する方式であり、認証情報の含め方や、暗号／署名方法などは標準化されているが、クライアント、サーバ側の両方に対応する必要があるため、やや敷居が高い。
【０００６】
第２の方式は、ＳＯＡＰボディ内に認証情報を含める方式である。これは、ＳＯＡＰメッセージのパラメータとして、認証情報を渡す方式であり、ＳＯＡＰのボディ内に認証情報を埋め込むものである。パラメータ内に認証情報が追加されてしまう問題はあるが、実際に運用されているＷｅｂサービス等で多くで利用実績がある。
【非特許文献１】ＯＭＡ−ＡＤ−Service_Environment-V1_0_4-20070201-A、 [online] 、 [２００８年８月２１日検索] 、インターネット〈http://www.openmobilealliance.org/Technical/release program/ose v1 0.aspx〉
【非特許文献２】山登庸次、大西浩行、中野雄介、“電話−Ｗｅｂ連携を促進する実行制御機能の検討”、電子情報通信学会  ２００８年総合大会講演論文集Ｂ−１９−１０
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、前述した第１の方式（ＳＯＡＰヘッダ）及び第２の方式（ＳＯＡＰボディ）においては、いずれか一方の方式によって要求される条件を満たすことは困難である。前述した第１の方式（ＳＯＡＰヘッダ方式）及び第２の方式（ＳＯＡＰボディ方式）について、Ｗｅｂサービス標準適合性、Ｐａｒｌａｙ−Ｘ（Parlay X Web Service）適合性、クライアント実装難易度、サーバ実装難易度の、４つの要求条件について比較した結果を図２に示す。図２において、「○」は要求条件を満たしていることを示し、「△」は要求条件を満たしていないことを示している。図２に示すように、いずれか一方の方式によって４つの要求条件を満たすことはできないという問題がある。また、従来技術においては、認証方式の異なるサービスコンポーネント（Ｗｅｂサービス）は認証方式別の対応を行う必要があり、連携して認証を行うことはできないという問題がある。このような問題を解決するためには、連携アプリケーションサーバと、サービスコンポーネントの間に認証情報を格納して、変換するための機能を設けることで認証方式の違いを吸収する必要があるが、従来技術においてはこのような構成は存在していないため、要求される認証方式が実現できないという問題がある。
【０００８】
本発明は、このような事情に鑑みてなされたもので、Ｗｅｂサービス等のサービスコンポーネントを連携して利用するシステムにおいて、クライアントがＷｅｂサービスを利用する際の認証方式が異なる場合に、異なる認証方式を併用してサービスコンポーネントや端末装置等の認証認可などの共通処理を行うことができる認証情報処理装置、認証情報伝達方法及び認証方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、通信対象のＷｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録手段と、クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択手段と、前記選択手段によって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡すことにより前記Ｗｅｂサービスと前記クライアントとの通信を行なわせる通信制御手段とを備えたことを特徴とする。
【００１０】
本発明は、前記通信は、ＳＯＡＰを用いた通信であることを特徴とする。
【００１１】
本発明は、前記２つの異なる認証方式は、前記認証情報がＳＯＡＰヘッダに含まれるＳＯＡＰヘッダ方式と、前記認証情報がＳＯＡＰボディに含まれるＳＯＡＰボディ方式のいずれかであることを特徴とする。
【００１２】
本発明は、通信対象のＷｅｂサービスとクライアントとの間で認証情報の伝達を行うための認証情報処理装置における認証情報伝達方法であって、前記認証情報処理装置が、前記Ｗｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録ステップと、前記認証情報処理装置が、前記クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択ステップと、前記認証情報処理装置が、前記選択ステップによって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから前記認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡すことにより前記Ｗｅｂサービスと前記クライアントとの通信を行なわせる通信制御ステップとを有することを特徴とする。
【００１３】
本発明は、前記通信は、ＳＯＡＰを用いた通信であることを特徴とする。
【００１４】
本発明は、前記２つの異なる認証方式は、前記認証情報がＳＯＡＰヘッダに含まれるＳＯＡＰヘッダ方式と、前記認証情報がＳＯＡＰボディに含まれるＳＯＡＰボディ方式のいずれかであることを特徴とする。
【００１５】
本発明は、通信対象のＷｅｂサービスとクライアントとの間で認証情報の伝達を行うことにより認証を行う認証方法であって、前記認証情報処理装置が、前記Ｗｅｂサービスが登録したＷＳＤＬ文書から２つの異なる認証方式それぞれのＷＳＤＬ文書を作成して登録する登録ステップと、前記認証情報処理装置が、前記クライアントからリクエストメッセージを受信した場合に、受信した前記リクエストメッセージの内容を分析して、前記２つの認証方式のいずれであるかを判定し、前記２つのＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する選択ステップと、前記認証情報処理装置が、前記選択ステップによって選択した前記ＷＳＤＬ文書に従って、前記受信したリクエストメッセージから前記認証情報を抽出し、前記Ｗｅｂサービスでサポートしている認証方式に合わせて、前記抽出した認証情報を前記Ｗｅｂサービスに対して受け渡す認証情報受け渡しステップと、前記Ｗｅｂサービスが、認証情報受け渡しステップによって受け渡された前記認証情報によって、前記クライアントの認証を行う認証ステップとを有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、Ｗｅｂサービス等のサービスコンポーネントを連携して利用するシステムにおいて、クライアントがＷｅｂサービスを利用する際の認証方式が異なる場合に、異なる認証方式を併用してサービスコンポーネントや端末装置等の認証認可などの共通処理を行うことができるという効果が得られる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一実施形態による認証情報処理装置を図面を参照して説明する。図３は同実施形態の構成を示すブロック図である。この図において、符号１は、認証情報処理を実行する実行制御サーバである。符号２は、パスワード認証処理やシングルサインオン処理を行う認証部である。符号３は、Ｗｅｂサービス利用時のＩＤフェデレーション処理、ＢＬ照合処理及びＷＬ照合を行う認可部である。符号４は、サービスの閉塞を確認するサービス閉塞確認部である。符号５は、転送ポリシを決定する転送ポリシ決定部である。符号６は、転送の実行制御を行う転送実行制御部である。符号７は、転送を行う場合の通信制御を行う転送通信制御部である。符号８は、サービスの緊急度に応じて優先制御を行いリクエストを優先的に転送したり、Ｗｅｂサーバ側の能力に応じて、リクエストの転送数を調整する（フロー規制）トラフィック制御部である。符号９は、メッセージレシーバ９１、メッセージハンドラ９２及びメッセージディスパッチャ９３から構成するメッセージインタセプタである。
【００１８】
次に、図３を参照して、実行制御サーバ１の機能の概要を説明する。まず、メッセージレシーバ９１が、リクエスタ１０からサービスの実行リクエストメッセージを受けると、転送先のサービスヘディスパッチする前に、転送実行制御部６や転送ポリシー決定部５によって認証認可処理を実行し、メッセージディスパッチャ９３が各Ｗｅｂサービスの実行を割り当てる。
【００１９】
一方、ＷｅｂサービスのＷＳＤＬ（Web Services Description Language）文書を実行制御サーバ１に登録する。以下の説明においては、ＷＳＤＬで記述したＸＭＬ文書のことをＷＳＤＬ文書と呼ぶことにする。このＷＳＤＬ文書の登録の際に、ＢＰＥＬ（Business Process Execution Language）検証部１１は、登録したサービスのチェックを行う。
【００２０】
メッセージレシーバ９１は、クライアントからメッセージを受け取り、メッセージハンドラ９２は、メッセージレシーバ９１が受け取ったメッセージから送信先のサービスがＷｅｂ  Ｓｅｒｖｉｃｅ  Ｓｅｃｕｒｉｔｙ（WS-Security）に対応しているか、または非対応であるかを判別し、それぞれに対応した処理を行う。メッセージディスパッチャ９３は、メッセージハンドラ９２が処理した情報を引き継ぎサービスに対して実際に転送を行う。
【００２１】
次に、図３、４を参照して、実行制御機能におけるＳＯＡＰ  Ｗｅｂサービス時の認証情報の受け渡し方式について説明する。ここで説明する認証情報の受け渡し方式では、実行制御機能におけるＷｅｂサービスのシングルサインオンによる認証認可を行う方式として、前述した第１の方式（ＳＯＡＰヘッダ方式）及び第２の方式（ＳＯＡＰボディ方式）の両方を組み合わせた両方式による認証方法を提供するものである。
【００２２】
まず、Ｗｅｂサービスが非公開のＷＳＤＬ文書５０の登録を行うと、実行制御サーバ１のサービス登録機能部９０は、登録されたＷＳＤＬ文書５０から、ＳＯＡＰボディ用ＷＳＤＬ文書６０と、ＳＯＡＰヘッダ用ＷＳＤＬ文書７０の二つを予め作成して登録する。ＳＯＡＰヘッダ用ＷＳＤＬ７０は、ＳＯＡＰリクエストのヘッダ（ＷＳ−Ｓｅｃｕｒｉｔｙのｕｓｅｒｎａｍｅ  ｔｏｋｅｎ）による認証に対応したクライアント２０が利用するＷＳＤＬ文書であり、資格証明（クライアントのユーザＩＤやＳＡＭＬ（Security Assertion Markup Language）のＡｓｓｅｒｔｉｏｎ）はＳＯＡＰリクエストのヘッダに設定され、元のＷＳＤＬ文書５０のエンドポイントを、実行制御サーバ１に変更する。元のＷＳＤＬ文書５０のエンドポイントは実行制御サーバ１内にキャッシュする。また、ＳＯＡＰヘッダのｕｓｅｒｎａｍｅ  ｔｏｋｅｎで認証情報を渡すためのＳＯＡＰヘッダ用ＷＳ−Ｐｏｌｉｃｙ８０を生成する。
【００２３】
一方、ＳＯＡＰボディ用ＷＳＤＬ文書６０は、ＢＰＥＬエンジン４０やＷＳ−Ｓｅｃｕｒｉｔｙ未対応のクライアント３０が利用するＷＳＤＬ文書であり、ＳＡＭＬのＡｓｓｅｒｔｉｏｎをＳＯＡＰリクエストのボディ（第一パラメータ）に追加し、元のＷＳＤＬ文書５０のエンドポイントを実行制御サーバ１に変更する。元のＷＳＤＬ文書５０のエンドポイントは実行制御サーバ１内にキャッシュする。なお、シングルサインオンでのＷｅｂサービス連携を行う場合はＳＯＡＰボディ用ＷＳＤＬ文書６０を利用する。
【００２４】
クライアントは、自身がサポートしている認証方式に応じて、上記二つの認証方式のいずれかの手順を用いて、実行制御サーバ１に対してリクエストを送信する。実行制御サーバ１のメッセージレシーバ９１ではクライアントのリクエストを受信し、メッセージハンドラ９２へ出力する。メッセージハンドラ９２は、受信したメッセージの内容を分析して、認証情報（資格証明）がＳＯＡＰのヘッダまたはボディのいずれに含まれているかを判定し、この判定結果に基づき、予め登録されている２つ（ヘッダ用とボディ用）のＷＳＤＬ文書のうち該当する認証方式のＷＳＤＬ文書を選択する。このとき、ヘッダとボディの双方に認証情報がある場合は正しくない要求（ＨＴＴＰ４００）であるものとしてエラーを返す。
【００２５】
そして、メッセージハンドラ９２は、選択したＷＳＤＬ文書に従って、受信したリクエストメッセージのヘッダもしくはボディから認証情報を抽出する。メッセージディスパッチャ９３は、通信対象のＷｅｂサービスでサポートしている認証方式に合わせて、抽出した認証情報をＷｅｂサービスに対して受け渡すことによりＷｅｂサービスとクライアントとの通信を行なわせる。
【００２６】
これにより、実行制御サーバ１においては、ＳＯＡＰヘッダ用ＷＳＤＬ文書と、ＳＯＡＰボディ用ＷＳＤＬ文書のうち、いずれのＷＳＤＬ文書を使って呼び出されたかを意識することなく、認証認可、トラフィック制御、ＳＬＡ制御等の実行制御サーバで行う共通処理を施し、Ｗｅｂサービス等にリクエストメッセージが転送されることになる。この際、実行制御サーバ１のメッセージディスパッチャ９３がリクエスト転送先の認証対応形式に応じて、自動的に認証情報の渡し方を変更する。
【００２７】
例えば、送信先のサービスが、一般的なＷｅｂサービスなどのＳＯＡＰヘッダやボディによる認証連携に対応していない場合、Ａｓｓｅｒｔｉｏｎ（ＡｓｓＮ）パラメータを削除して転送する。書き換えのルールはサービスのＷＳＤＬ文書を登録する際に、サービスが対応する認証方式を手動で選択する。入力された情報は実行制御サーバ１の認可部３に保存され、利用時に認可方式を検索し、それに応じて転送リクエストの書き換えを自動で行う。
【００２８】
次に、図５を参照して、認証連携処理の具体的なアーキテクチャ例を説明する。クライアントであるエンドユーザＡ（ＵｓｅｒｎａｍｅがＡ）が実行制御サーバ１（説明を簡単にするために図５においては実行制御サーバ１を「Ｐ」と表記する）に対して認証要求を行う（図５に示す（１））。その際送信するＳＯＡＰのヘッダ内にはユーザの名前と、パスワードを入れる。次に、実行制御サーバ１が、認証局Ｘに対して認証の要求を行う（図５に示す（２））と、ＳｕｂｊｅｃｔがＡであり、認証局Ｘの署名が添付されたＡｓｓＮが返ってくる。
【００２９】
実行制御サーバ１にエンドユーザからＵｓｅｒｎａｍｅ  Ｔｏｋｅｎが渡された場合には、パスワード認証（非ドメイン発）、またはＨＴＴＰＳクライアント認証（ドメイン発）を実施する。次に、送信先のサービスがＷＳ−Ｓｅｃｕｒｉｔｙ（ＷＳＳと表記する）に対応している（ＳＡＭＬ  Ｔｏｋｅｎ）の場合は、ＡｓｓＮをＷＳＳヘッダに載せて、送信元である実行制御サーバ１の署名（Ｐの署名）をつけて転送する（図５に示す（３））。
【００３０】
この場合、ＷＳＳに対応しているＢＰＥＬエンジン（αと表記する）等を利用した場合のアーキテクチャである。メッセージを受け取ったＢＰＥＬエンジンは、実行制御サーバ１の署名（Ｐの署名）を検証して、リクエストを投入後、新しいＳＯＡＰ  Ｅｎｖｅｌｏｐｅを作成して、ＡｓｓＮを引き継ぎ、自身（ＢＰＥＬエンジン）の署名（αの署名）を添付して送信する（図５に示す（４））。次に、ＳＡＭＬ  Ｔｏｋｅｎを渡された実行制御サーバ１では、α（ＢＰＥＬエンジン）とＸ（認証局）の署名を検証し、認証確認を実施後、送信先のＷｅｂサービスがＷＳＳ非対応の場合はＳＯＡＰヘッダを削除して転送する（図５に示す（５））。
【００３１】
以上説明したように、方式の異なる２つの認証情報の受け渡し方式を提供することによって、ＳＯＡＰヘッダ方式、ＳＯＡＰボディ方式のいずれか一方を提供した場合の問題を解決することができる。ＳＯＡＰヘッダ方式はＷＳ−Ｓｅｃｕｒｉｔｙに対応しているクライアントに向けた認証方式であり、この場合Ｐａｒｌａｙ−Ｘの拡張とならない利点がある。一方、ＳＯＡＰボディ方式は、複数のＷｅｂサービスで同じ認証情報を引き継いで、共有利用するＢＰＥＬエンジンや、ＷＳ−Ｓｅｃｕｒｉｔｙに対応していないクライアントに向けた認証方式である。前述した本発明による方式を用いることによって、両者の要望に応えた認証方式を提供することができる。
【００３２】
ＳＯＡＰヘッダ方式の場合、ＳＯＡＰヘッダに情報を格納するためのクライアント実装難易度の問題、また、ＷＳ−Ｓｅｃｕｒｉｔｙ対応ＳＯＡＰミドルウェアが少ないという問題（ｕｓｅｒｎａｍｅ  ｔｏｋｅｎはサポートも多いが、ＳＡＭＬ  ｔｏｋｅｎはサポート外である）、ＷＳ−Ｐｏｌｉｃｙを理解できる技術者が少ないという問題、市販のＢＰＥＬ、ＥＳＢ製品ではＳＯＡＰヘッダ情報を引き回せないことが多いため、認証ｔｏｋｅｎを引き回して、複数のＷＳを連携することは困難であるという問題（ＷＳ−Ｓｅｃｕｒｉｔｙのｕｓｅｒｎａｍｅ  ｔｏｋｅｎはサポートも多いが、ＳＡＭＬ  ｔｏｋｅｎはサポート外である）を有しているが、本発明による認証情報の処理方法を適用することによりこのような問題を解決することができる。また、ＳＯＡＰボディ方式の場合、署名／暗号化の仕方等が標準化されていないという問題、パラメータが追加になるため、Ｐａｒｌａｙ−Ｘの拡張となってしまい標準から外れてしまうという問題を有しているが、本発明による認証情報の処理方法を適用することによりこのような問題を解決することができる。
【００３３】
このように、複数のＷｅｂサービスを連携させて柔軟なＷｅｂサービスを提供する場合に、個々のＷｅｂサービスを連携させるサービス連携装置において、既存の２つの認証方式（ＳＯＡＰヘッダ方式とＳＯＡＰボディ方式）の両方をサポートする場合に、それぞれの認証方式を個別にサービス連携装置に実装すると実装量が冗長になる。しかし、前述したように、本発明は、２つの認証方式に合わせた２つのＷＳＤＬ文書を元々のＷＳＤＬ文書から予め作成して登録するともに、実行制御サーバ１には端末等のクライアントからの受信メッセージを事前に処理する機能を持たせておき、受信したリクエストメッセージの内容の分析結果からいずれの認証方式であるかを判定し、登録しておいた２つのＷＳＤＬ文書のうち、該当するＷＳＤＬ文書を選択するようにした。そして、選択したＷＳＤＬ文書に従い、クライアントとの通信を行い、認証などのその後の処理に必要な情報を含むメッセージを受信し、メッセージのヘッダまたはボディから認証情報を抽出して以降の処理を行い、Ｗｅｂサービスにおいてサポートされている認証方式に合わせてＷｅｂサービスとの通信を行うようにした。
【００３４】
このような構成とすることにより、クライアントは、自身がサポートしている認証方式に基づくリクエストを実行制御サーバに送るだけでよく、実行制御サーバではメッセージの事前処理によって認証処理に必要な認証情報を抽出することにより、以降の認証処理はいずれの認証方式においても共通とすることができるため、実装を共通化することができ、実装量を減らすことが可能となり、従来技術の問題点を解決することができる。また、Ｗｅｂサービス側は、元々登録した自身の認証方式に合わせたメッセージが送られることになるため、リクエスタ側の認証方式に合わせることなく処理を実行することができる。
【００３５】
なお、図３に示す実行制御サーバ１の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより認証情報処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【００３６】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【図面の簡単な説明】
【００３７】
【図１】ＳＯＡＰ  Ｗｅｂサービス利用時の認証情報の受け渡し方として実装されている２つの方式を示す説明図である。
【図２】ＳＯＡＰヘッダ方式及びＳＯＡＰボディ方式において、Ｗｅｂサービス標準適合性、Ｐａｒｌａｙ−Ｘ適合性、クライアント実装難易度、サーバ実装難易度の、４つの要求条件について比較した結果を示す説明図である。
【図３】本発明の一実施形態の構成を示すブロック図である。
【図４】実行制御機能におけるＳＯＡＰ  Ｗｅｂサービス時の認証情報の受け渡し方式を示す説明図である。
【図５】認証連携処理のアーキテクチャ例を示す説明図である。
【符号の説明】
【００３８】
１・・・実行制御サーバ、２・・・認証部、３・・・認可部、４・・・サービス閉塞確認部、５・・・転送ポリシ決定部、６・・・転送実行制御部、７・・・転送通信制御部、８・・・トラフィック制御部、９・・・メッセージインタセプタ、２０、３０・・・クライアント、４０・・・ＢＰＥＬエンジン、５０・・・ＷＳＤＬ文書、６０・・・ＳＯＡＰボディ用ＷＳＤＬ文書、７０・・・ＳＯＡＰヘッダ用ＷＳＤＬ文書、８０・・・ＳＯＡＰヘッダ用ＷＳ−Ｐｏｌｉｃｙ、９０・・・サービス登録機能部
【図１】
2010092407.tif 000003
【図２】
2010092407.tif 000004
【図３】
2010092407.tif 000005
【図４】
2010092407.tif 000006
【図５】
2010092407.tif 000007