JP2009230354A - サービス管理方法及びサービス管理システム - Google Patents

Abstract

【課題】ネットワーク上のサービスコンポーネントをサービスリクエスタが利用する際に、認証、認可の共通処理を一括して行う。
【解決手段】サービスコンポーネント提供端末３は、サービスコンポーネントを提供する端末である。サービスリクエスタ端末５は、サービス利用要求を行う端末である。サービスリクエスタ端末５から利用要求がサービス管理機能部２に送信されると、サービス管理機能部２は、認証、認可、ＩＤ変換処理を行い、サービスコンポーネント提供端末３がサービスコンポーネントを提供する。また、連携サービスシナリオ実行端末４は、連携サービスの実行要求を受ける際に、サービスコンポーネント提供端末３と同様のサーバとして動作し、複数のサービスコンポーネントの利用要求を行う際に、サービスリクエスタ端末５と同様のクライアントとして動作する。
【選択図】図１

Description

本発明は、Ｗｅｂサービス等のサービスコンポーネントを連携して利用するシステムにおける、サービスコンポーネントの認証認可などの共通処理を行うサービス管理方法及びサービス管理システムに関する。

Ｗｅｂサービス等のサービスコンポーネントを利用、または、連携利用することで、新たなサービスを容易に実現する試みがある（例えば、非特許文献１参照）。また、ＢＰＥＬ（Business Process Execution Language）等のＷｅｂサービスを連携する記述言語も標準化されてきている（例えば、非特許文献２参照）。

サービスコンポーネントを連携することで、様々なサービスを実現する方法は、サービス指向アーキテクチャというキーワードで呼ばれ、広く普及している。Ｗｅｂサービス等の標準的なサービスコンポーネントの連携によるサービス実現は、今後、ますます発展していくと考えられる。

ところで、異なる管理組織（ドメイン）のサービスコンポーネントを利用する際には、認証、認可や、識別子（ＩＤ）変換などが必要である。例えば、ＡプロバイダのサービスとＢプロバイダのサービスを使う際には、それぞれ異なるＩＤでログインする必要がある。このように、個別の認証、認可があることで、サービス利用者（リクエスタ）、およびサービスコンポーネント提供者とも、安全なサービスコンポーネントの利用、提供が可能になる。

多数のサービスコンポーネントを複数回利用するサービスリクエスタにとっては、個々のサービスコンポーネントに対して、認証、認可を練り返し行うことは負担が大きい。また、サービスコンポーネント提供側にとっても、認証、認可などの処理（プログラム）を作成することは、コンポーネント作成コストが大きくなるという欠点がある。

しかしながら、上述した非特許文献１、２では、サービスコンポーネントを利用する際の認証や、認可などの共通処理については、あまり考えられていない。

そこで、サービスコンポーネントの認証などを一括して行う技術が提案されている（例えば、非特許文献３参照）。該非特許文献３による従来技術では、サービスリクエスタとサービスコンポーネントとの間を仲介する仲介者を設けることで、サービスリクエスタにおいては、何回も認証する手間を省き、サービスコンポーネント側においては、認証、認可処理を作成するという負担をなくす。また、上述した非持許文献３以外にも、Ｗｅｂサービスの認証や、認可、ＩＤ変換などを行う製品が市販されている（例えば、非特許文献４）。
山登康次、中辻真、須永宏、"ユビキタス環境にて動的にサービス実現するためのサービス合成技術"、情報処理学会論文誌、vol.48、No.2、pp.562-577、Feb、2007 Business Process Execution Language 200803211415212030__________NTTH196580__________________APH_0.htm H. Ohnishi, et al., "New service creation platform for Telecom-Enterprise-Internet combined services", IEEE GLOBECOM2007, Nov. 2007. Oracle Web Service Manager, http://otn.oracle.co.jp/products/webservices_manager/

しかしながら、上述した非持許文献３は、サービスコントロールファンクションが、ＳＡＭＬ（Security Assertion Markup Language）を用いて認証、認可するとされているが、具体的にどのように認証、認可を行うかは、記述されていない。また、上述した非特許文献４による従来技術では、認証、認可を、毎回、データベースに問合せるため、データベースへのアクセスの処理時間が大きいという問題がある。また、認証、認可は共通化されているが、ＩＤ変換はないなど、全ての共通処理を一括化するには、別製品と組み合わせる必要があったり、連携するアダプタを作成する必要があったりなど、効率が悪いという問題がある。

本発明は、このような事情を考慮してなされたものであり、その目的は、ネットワーク上のサービスコンポーネントをサービスリクエスタが利用する際に、認証、認可の共通処理を一括して行うことができ、また、サービスリクエスタの認証処理を軽減し、サービスコンポーネント提供者が認証、認可の共通処理を準備する負担を軽減することができ、さらに、認証、認可を高速に行うことができるサービス管理方法及びサービス管理システムを提供することにある。

上述した課題を解決するために、本発明は、サービスリクエスタ端末からのサービスリクエスタに対して、単数のサービスコンポーネントの利用もしくは複数のサービスコンポーネントを連携して利用可能にする際に、個々のサービスコンポーネントの認証、認可を行うサービス管理方法であって、前記サービスリクエスタ端末からの認証要求に基づいて認証を行うステップと、前記認証が正当に行われると、前記サービスリクエスタ端末に対して認証チケットを発行するステップと、前記サービスリクエスタ端末のサービスコンポーネント利用時に送信するサービス利用要求に付与されている前記認証チケットの正当性を認証するステップと、前記認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかの認可を行うステップと、前記サービスコンポーネントの利用が認可された場合、当該サービス利用要求をサービスコンポーネントに転送するステップと、を含むことを特徴とするサービス管理方法である。

本発明は、上記の発明において、前記認証または認可のいずれかに問題があった場合、前記サービス利用要求の要求エラーを前記サービスリクエスタ端末に転送するステップをさらに含むことを特徴とする。

本発明は、上記の発明において、前記認証は、パスワード、生体情報、証明書のいずれかを用いて照合することで行うことを特徴とする。

本発明は、上記の発明において、前記認証チケットは、少なくとも、サービスリクエスタ識別子と、発行した認証局の認証情報とを含むことを持徴とする。

本発明は、上記の発明において、前記認証チケット発行時にサービスリクエスタ端末の認証情報を第１の記憶手段に保持するステップと、前記サービスリクエスタ端末からサービス利用要求があった際には、前記サービス利用要求に付与された認証チケットが正当であるかを、前記第１の記憶手段に保持された認証情報と比較して確認するステップとをさらに含むことを特徴とする。

本発明は、上記の発明において、前記認証チケットが他の認証局により発行されたものであった場合、正しく認証されたかどうかを、前記他の認証局に問い合わせるステップと、前記認証チケットの正当性が認証された場合、該当認証情報を前記第１の記憶手段に保持するステップとをさらに含み、前記サービスリクエスタ端末から同じサービス利用要求が再度あった際には、前記サービス利用要求に付与された認証チケットが正当であるかを、前記第１の記憶手段に保持された認証情報と比較して確認することを特徴とする。

本発明は、上記の発明において、前記認可の正当性が確認された場合、サービス利用要求に対応する認可情報を第２の記憶手段に保持するステップと、前記サービスリクエスタ端末から、再度同じサービスコンポーネント利用要求または異なるサービスコンポーネント利用要求があった際に、かつ該サービス利用要求に付与された認証チケットの正当性が認証された場合に、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかを、前記第２の記憶手段に保持された認可情報と比較して確認するステップと、をさらに含むことを特徴とする。

本発明は、上記の発明において、前記認証・認可の正当性が確認された場合、サービス利用要求転送前に、前記認証チケットに記載されたサービスリクエスタ識別情報を、実際のサービスコンポーネントで用いられるサービスコンポーネント識別情報に変換するステップをさらに含むことを特徴とする。

また、上述した課題を解決するために、本発明は、サービスリクエスタ端末からのサービスリクエスタに対して、単数のサービスコンポーネントの利用もしくは複数のサービスコンポーネントを連携して利用可能にする際に、個々のサービスコンポーネントの認証、認可を行うサービス管理システムであって、前記サービスリクエスタ端末からの認証要求に基づいて認証を行う認証要求受付手段と、前記認証受付手段により認証が正当に行われると、前記サービスリクエスタ端末に対して認証チケットを発行する認証チケット発行手段と、前記サービスリクエスタ端末のサービスコンポーネント利用時に送信するサービス利用要求に付与されている前記認証チケットの正当性を認証する認証手段と、前記認証手段により認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかの認可を行う認可手段と、前記認可手段によりサービスコンポーネントの利用が認可された場合、当該サービス利用要求をサービスコンポーネントに転送する転送制御手段と、を備えることを特徴とするサービス管理システムである。

この発明によれば、サービスリクエスタ端末からの認証要求に基づいて認証を行い、認証が正当に行われると、サービスリクエスタ端末に対して認証チケットを発行し、サービスリクエスタ端末のサービスコンポーネント利用時に認証チケットの正当性を認証し、認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかの認可を行い、サービスコンポーネントの利用が認可された場合、当該サービス利用要求をサービスコンポーネントに転送する。したがって、ネットワーク上のサービスコンポーネントをサービスリクエスタが利用する際に、認証、認可の共通処理を一括して行うことができ、また、サービスリクエスタの認証処理を軽減し、サービスコンポーネント提供者が認証、認可の共通処理を準備する負担を軽減することができ、さらに、認証、認可を高速に行うことができるという利点が得られる。

また、本発明によれば、認証または認可のいずれかに問題があった場合、サービス利用要求の要求エラーを、サービスリクエスタ端末に転送する。したがって、サービスリクエスタの認証処理を軽減し、サービスコンポーネント提供者が認証、認可の共通処理を準備する負担を軽減することができ、さらに、認証、認可を高速に行うことができるという利点が得られる。

また、本発明によれば、パスワード、生体情報、証明書のいずれかを用いて照合することで認証の正当性を確認する。したがって、既存の方法で容易に認証することができるという利点が得られる。

また、本発明によれば、認証チケットは、少なくとも、サービスリクエスタ識別子と、発行した認証局の認証情報とを含む。したがって、認証、認可の共通処理を一括して行うことができ、また、サービスリクエスタの認証処理を軽減し、サービスコンポーネント提供者が認証、認可の共通処理を準備する負担を軽減することができ、さらに、認証、認可を高速に行うことができるという利点が得られる。

また、本発明によれば、認証チケット発行時にサービスリクエスタ端末の認証情報を第１の記憶手段に保持し、サービスリクエスタ端末からサービス利用要求があった際には、認証チケットが正当であるかを、第１の記憶手段に保持された認証情報と比較して確認する。したがって、認証を高速に行うことができるという利点が得られる。

また、本発明によれば、認証チケットが他の認証局により発行されたものであった場合、正しく認証されたかどうかを、他の認証局に問い合わせ、認証チケットの正当性が認証された場合、該当認証情報を第１の記憶手段に保持し、同じサービス利用要求が再度あった際には、認証チケットが正当であるかを、第１の記憶手段に保持された認証情報と比較して確認する。したがって、他の認証局により発行されたものであっても、認証を高速に行うことができるという利点が得られる。

また、本発明によれば、認可の正当性が確認された場合、サービス利用要求に対応する認可情報を第２の記憶手段に保持し、再度同じサービスコンポーネント利用要求または異なるサービスコンポーネント利用要求があり、かつ該サービス利用要求に付与された認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかを、第２の記憶手段に保持された認可情報と比較して確認する。したがって、認可を高速に行うことができるという利点が得られる。

また、本発明によれば、認証・認可の正当性が確認された場合、サービス利用要求転送前に、認証チケットに記載されたサービスリクエスタ識別情報を、実際のサービスコンポーネントで用いられるサービスコンポーネント識別情報に変換する。したがって、ネットワーク上のサービスコンポーネントをサービスリクエスタが利用する際に、認証、認可の共通処理を一括して行うことができるという利点が得られる。

以下、本発明の一実施形態を、図面を参照して説明する。

（システム構成）
図１は、本発明の実施の形態におけるシステムの構成例を示すブロック図である。図１において、システムは、ネットワーク１と、サービス管理機能部２と、サービスコンポーネント提供端末３、連携サービスシナリオ実行端末４、サービスリクエスタ端末５、他認証局６とから構成されている。各端末は、ネットワーク１に接続されている。

ネットワーク１は、電話交換等の通信ネットワーク、あるいはインターネット等の情報ネットワーク、あるいは移動体ネットワーク等からなる。サービス管理機能部２は、サービスリクエスタ端末５や、連携サービスシナリオ実行端末４などがサービスコンポーネントを利用する際に、個々のサービスコンポーネントの認証や、認可、ＩＤ（識別子）変換等の共通処理を一括して行う。詳細については後述する。

サービスコンポーネント提供端末３は、サービスコンポーネントを提供する端末であり、サービス利用要求に応じて、何らかの処理を行う。サービスコンポーネントは、例えば、Ｗｅｂサービス、ＵＰｎＰ（Universal Plug and Play）デバイス、ＣＯＲＢＡ等の、ネットワークを介して機能を利用することができる実体である。

サービスリクエスタ端末５は、サービス利用要求を行う端末である。サービスリクエスタ端末５は、サービスコンポーネントを利用する際に、事前にサービス管理機能部２または他認証局６により認証を行って認証チケットを発行してもらい、その認証チケットをサービス利用要求に付与してリクエストを行う。

連携サービスシナリオ実行端末４は、複数のサービスコンポーネントを連携したサービスを実行する端末であり、サービスリクエスタ端末５からのサービス利用要求に応じて、複数のサービスコンポーネントを連携する。サービス連携シナリオとしては、Ｗｅｂサービスが連携する、ＢＰＥＬ等の標準技術が挙げられるが、ＢＰＥＬでなくとも、複数のサービスコンポーネントを連携する端末であればよい。

なお、連携サービスシナリオ実行端末４は、連携サービスの実行要求を受ける際には、サービスコンポーネント提供端末３と同様のサーバとして動作し、複数のサービスコンポーネントの利用要求を行う際には、サービスリクエスタ端末５と同様のクライアントとして動作する。このため、特に、連携サービスシナリオ実行端末４の固有処理がない場合に、連携サービスシナリオ実行端末４がクライアントとして動作する際には、サービスリクエスタ端末５と合わせてサービスリクエスタ端末として動作し、連携サービスシナリオ実行端末４がサーバとして動作する際は、サービスコンポーネント提供端末３と合わせてサービスコンポーネント提供端末として動作する。

他認証局６は、サービス管理機能部２以外の認証局であり、サービスリクエスタ端末５の認証を行い、認証が成功した場合には、認証チケットを発行する。また、サービス管理機能部２により、発行された認証チケットが妥当であるかどうかの検証依頼を受け、その結果を返す。

なお、図面の都合上、サービスコンポーネント提供端末３等は、１つずつ示しているが、それぞれ複数存在してもよい。また、図１に示す各機能要素は、独立して存在することも、併合して存在することも可能となっている。また、他認証局６は、本システムに必須ではない。

（システム機能）
本実施形態によるシステムの機能は、サービスリクエスタ端末５がサービスコンポーネント提供端末３に利用要求を送る際に、個々のサービスコンポーネントの認証、認可の共通処理をサービス管理機能部２が一括して行い、認証、認可に成功した利用要求のみ、サービスコンポーネント提供端末３に転送するようになっている。

図２（ａ）、（ｂ）は、本実施形態による、サービスリクエスタ端末５、サービスコンポーネント提供端末３、サービス管理機能部２、連携サービスシナリオ実行端末４の関係を示すブロック図である。図２（ａ）には、１つのサービスシナリオを実行する通常の形態を示しており、サービスリクエスタ端末５から利用要求をサービス管理機能部２に送信すると、サービス管理機能部２が、認証、認可、ＩＤ変換処理を行い、サービスコンポーネント提供端末３がサービスコンポーネントを提供する。

図２（ｂ）には、連携サービスシナリオ実行端末が連携する場合の形態を示しており、連携サービスシナリオ実行端末４は、連携サービスの実行要求を受ける際には、サービスコンポーネント提供端末３と同様のサーバとして動作する一方、複数のサービスコンポーネントの利用要求を行う際には、サービスリクエスタ端末５と同様のクライアントとして動作する。連携サービスシナリオ実行端末４がサーバとして動作する際は、サービスコンポーネント提供端末３と合わせてサービスコンポーネント提供端末として動作する。一方、連携サービスシナリオ実行端末４がクライアントとして動作する場合には、サービスリクエスタ端末５と合わせてサービスリクエスタ端末として動作する。

いずれの場合も、サービス管理機能部２が、認証、認可処理を一括処理することで、サービスリクエスタ端末５は、複数のサービスコンポーネント毎に、個別に認証を行う手間が軽減され、サービスコンポーネント提供端末３は、認証、認可の共通処理を行う必要がなくなる。さらに、本実施形態では、後述する機能により、認証、認可を、キャッシュを用いて高速に行うことができる。

（サービス管理機能部の構成）
次に、上述したサービス管理機能部２の構成について説明する。
図３は、本実施形態によるサービス管理機能部２の構成を示すブロック図である。なお、同図は、サービス管理機能部２のうち、本発明に係る部分のみを概念的に示している。図３において、サービス管理機能部２は、認証要求受付機能部２−１、メッセージプロキシ機能部２−２、転送制御機能部２−３、認証機能部２−４、他認証局問合機能部２−５、認証用ＤＢ２−６、認可機能部２−７、認可用ＤＢ２−８、ＩＤ変換機能部２−９、ＩＤ変換用ＤＢ２−１０、およびサービスコンポーネント情報ＤＢ２−１１から構成されている。

認証要求受付機能部２−１は、サービス管理機能部２が自ら認証チケットを発行する際に利用される。認証要求受付機能部２−１は、サービスリクエスタ端末５から、サービス管理機能部２に対して認証を要求するリクエスト（ログイン要求）を受け付ける。サービスリクエスタ端末５は、認証する際に、サービスリクエスタ識別子と、パスワードや、生体情報、証明書などの個人識別情報を送信する。認証要求受付機能部２−１は、これらの情報を受け取り、認証機能部２−４に供給する。また、認証機能部２−４から認証成功であったことが通知された場合には、認証チケットを受け取り、認証チケットを認証成功結果とともに、サービスリクエスタ端末５に返送する。

メッセージプロキシ機能部２−２は、サービスリクエスタ端末５からのサービスコンポーネント利用要求をサービスコンポーネント提供端末３に送る前のプロキシとして、サービス利用要求の中身を解析し、転送制御機能部２−３にサービス利用要求内の認証チケットや、パラメータ情報などを供給する。パラメータ情報には、どのサービスコンポーネントのどのオペレーションや、メソッドなどを実行しようとしているか、あるいは、そのオペレーションや、メソッドなどの引数等が含まれる。また、メッセージプロキシ機能部２−２は、転送制御機能部２−３から、転送可の指示であるサービス利用要求が供給された場合に、実体のサービスコンポーネント提供端末３にサービス利用要求を転送する。これに対して、転送不可の場合には、サービスリクエスタ端末５に転送不可の原因とエラー応答とを送信する。

転送制御機能部２−３は、サービス利用要求を、サービスコンポーネント提供端末３に転送してよいかを判断するため、メッセージプロキシ機能部２−２から受け取った認証チケットを認証機能部２−４に供給し、認証が正当であるかの認証チェックを行わせ、認証が成功した場合には、認可機能部２−７を用いて、認証されたサービスリクエスタ端末５がサービスコンポーネント提供端末３を利用してよいかの認可チェックを行う。

なお、認可機能部２−７は、認可が成功した場合に、必要に応じてＩＤ変換機能部２−９を呼び出し、ＩＤ変換を行った後に、転送制御機能部２−３にサービス利用要求情報を返す。転送制御機能部２−３は、認証、認可、ＩＤ変換などの処理が終わると、転送してよいサービス利用要求情報を、メッセージプロキシ機能部２−２に供給する。転送制御機能部２−３は、認証や、認可などに失敗した場合は、サービス利用要求が転送不可であるとして、原因（認可失敗など）をメッセージプロキシ機能部２−２に供給する。また、後述するように、転送制御機能部２−３は、認証、認可、ＩＤ変換などの全ての処理を行わずに、サービスコンポーネントに応じて、利用する処理を選択的に行ってもよい。

認証機能部２−４は、認証要求受付機能部２−１からの認証要求時に、認証用ＤＢ２−６に保持されている、サービスリクエスタ識別子とそれに対応する情報（パスワード、生体情報の個人識別情報）を照合して、認証成功か、失敗かを判定し、成功した場合には、認証チケットを発行して認証要求受付部２−１に供給し、失敗した場合には、失敗原因を認証要求受付部２−１に供給する。認証チケットを発行する場合には、認証情報（識別子、有効期間、発行者認証実施時刻、認証方式など）が認証機能部２−４のメモリに展開され、キャッシュされる。

また、認証機能部２−４は、サービス利用要求時に、転送制御機能部２−３から認証確認依頼を受け、サービス利用要求に付与された認証チケットの検証を行う。発行者が他認証局６の場合も、既にキャッシュされた認証情報がある場合（２回目以降の利用）には、その認証情報と照合することで認証確認を行う。認証確認では、有効期限が切れていないか、改ざんされていないか、などの正当性を確認する。

他認証局６が発行した、認証チケットを使った、１回目のサービス利用要求の場合には、キャッシュされた認証情報がないため、他認証局６に問い合わせる。あるいは、認証チケットに記述された発行者と電子署名などを理由に正当に認証されたと判断する。他認証局６に問い合わせる際には、認証チケットを他認証局問合機能部２−５に渡し、その他認証局６が正当に認証したかどうかの問い合わせを行わせ、正当性を確認する。但し、信頼できる発行者であり、電子署名が行われており、改ざんされていない等が分かる場合には、問い合わせを行わなくてもよい。

また、認証機能部２−４は、１回目のサービス利用要求で、他認証局に問い合わせるか、または、信頼できるなどで認証確認が成功した場合には、認証情報をキャッシュする。また、認証機能部２−４は、認証確認の成功、失敗の結果を転送制御機能部２−３に返す。また、認証機能部２−４は、認証要求受付部２−１からログアウト要求があった場合には、キャッシュされた認証情報を消去し、認証チケットの効果を削除する。

他認証局問合機能部２−５は、他認証局６が発行した認証チケットがサービス利用要求に付与されていた場合に利用される。他認証局問合機能部２−５には、認証機能部２−４に渡された認証チケットの発行者が他認証局６であり、認証情報キャッシュがない場合に、認証機能部２−４から、その認証チケットの正当性を確認するために、他認証局６に本当に正しく認証されたかどうかを問い合わせるため、認証チケットが渡される。

他認証局問合機能部２−５は、認証チケットに記述された発行者情報を見て、発行者に問い合わせを行う。問い合わせを行う方式は、一般のＷｅｂシステムで用いられている方式、例えば、ＳＡＭＬ標準で決められている方式などを用いればよい。他認証局６は、問い合わせを受けると、自らが認証した結果を参照し、正しく認証されているかどうかを返答する。他認証局問合機能部２−５は、他認証局６の認証結果を認証機能部２−４に返す。認証用ＤＢ２−６は、最初の認証チケット発行の際に参照される。認証用ＤＢ２−６には、サービスリクエスタ識別子とその識別子に該当する情報（パスワード、生体情報などの個人識別情報）が保持されており、認証機能部２−４での認証チケット発行の際に用いられる。

認可機能部２−７は、転送制御機能部２−３から認可依頼を受けて、認証されたサービスリクエスタ端末５が、サービス利用要求に該当するサービスコンポーネントを利用してよいかを判定する。利用してよいかの判定は、認証チケット発行後の初回には、認可用ＤＢ２−８からサービスリクエスタ端末５がどのサービスコンポーネントを現在利用してよいかの情報を取得し、それと照合することで認可を行う。これらの情報は、認可機能部２−７にキャッシュされる。また、このとき、後述するサービスリクエスタのＩＤ変換情報もＩＤ変換用ＤＢ２−１０から取得され、ＩＤ変換機能部２−９にキャッシュされる。

認証チケット発行後の２回目以降は、サービスリクエスタがどのサービスコンポーネントを利用してよいかの情報が既にキャッシュされているため、それと照合することで認可を行う。認可機能部２−７は、認可が成功した場合には、利用要求されたサービスコンポーネントが、ＩＤ変換が必要なコンポーネントに対しては、ＩＤ変換機能部２−９を呼び出し、認証チケットに記述されたサービスリクエスタＩＤを、サービスコンポーネントを利用する際のＩＤに変換させる。認可機能部２−７は、ＩＤ変換の終了後に、認可の成功、失敗の結果を転送制御機能部２−３に返す。認可が成功し、かつ、ＩＤ変換が必要なコンポーネントであった場合には、ＩＤ変換がなされている。

認可用ＤＢ２−８は、サービスリクエスタがどのサービスコンポーネントを現在利用してよいかの情報を保持している。この情報は、認可機能部２−７での、認可の際に用いられる。なお、現在利用してよい状態とは、サービスリクエスタ端末５が利用してよいという契約を結んでいる、あるいは、誰でも利用してよいという規約になっている、だけでなく、そのサービスコンポーネントが現在サービスを提供しているか（サービスコンポーネント提供端末３が停止していないか）、サービスリクエスタが悪意あるユーザとしてリクエストを排除するよう設定されていないか、などの条件も含まれる。

ＩＤ変換機能部２−９は、認可終了後に、認可機能部２−７で認可されたＩＤとサービスコンポーネントを利用する際に必要となるＩＤとが異なる場合にＩＤの変換を行う。例えば、サービス管理機能部２では、「１２３４」というＩＤで認証を受けたが、サービスコンポーネントａを利用する際は、「ａｂｃｄ」というＩＤで利用する必要があることが、異なるドメインのサービスの場合に多い（ドメイン毎に異なるＩＤで管理されている場合など）。また、サービスコンポーネントａを利用する際には、異なるＩＤだけでなく、そのＩＤとパスワードとを入力する必要がある。

このような場合には、認証は既に済んでいるため、サービスリクエスタ端末５で別のＩＤを入力してもらう手間を省くため、ＩＤ変換機能部２−９が、サービスリクエスタ端末５がサービス管理機能部２に対して認証を行うＩＤと、そのサービスリクエスタ端末５がサービスコンポーネントを利用する際のＩＤや、パスワード等のマッピング情報を利用してＩＤを変換する。なお、実際には、ＩＤ変換時は、認可機能部２−７での最初の認可の際に、ＩＤ変換情報もＩＤ変換用ＤＢ２−１０からキャッシュされているため、該キャッシュ情報を用いてＩＤ変換が行われる。

ＩＤ変換用ＤＢ２−１０は、サービスリクエスタ端末５がサービス管理機能部２または他認証局６に対して認証を行う際に用いるＩＤと、そのサービスリクエスタ端末５がサービスコンポーネントを利用する際に用いるＩＤとのマッピング情報を保持しており、これらの情報は、ＩＤ変換の際に用いられる。

サービスコンポーネント情報ＤＢ２−１１は、実体サービスコンポーネントの宛先（エンドポイント）や、そのサービスコンポーネントが認証、認可、ＩＤ変換が必要であるか否かの情報などを保持する。ＩＤ変換としては、広義には、（１）認証チケットのＩＤ関連情報をサービスコンポーネント用のＩＤ関連情報に変換するタイプ（サービスコンポーネント独自のＩＤ関連情報が必要な場合）、（２）認証チケットのＩＤ関連情報を削除するタイプ（サービスコンポーネント側ではＩＤ関連情報が不要な場合）、（３）認証チケットのＩＤ関連情報を引き継ぐタイプ（認証チケットの情報をサービスコンポーネント側で利用する場合、例えば、後述する連携サービスシナリオ実行端末の場合）がある。（１）の場合にＩＤ変換機能が行われる。（３）の場合には、認証チケット情報をそのまま渡せばよい。また、（２）の場合には、認証チケット情報がサービスコンポーネント側に渡らないように、認可機能部２−７で削除される。

ここで、図４は、上述したＩＤ変換、ＩＤ削除、ＩＤ引き継ぎの３つのパターンを示す概念図である。図４において、上記（１）に対応する置換型では、受信したリクエストに記述されているＩＤ「１２３４」が、あるプロバイダの別ＩＤである「ａｂｃｄ」に変換される。また、上記（２）に対応する削除型では、受信したリクエストに記述されているＩＤ「１２３４」が削除される。また、上記（３）に対応する継承型では、受信したリクエストに記述されているＩＤ「１２３４」がそのまま引き継がれる。

サービスコンポーネント情報ＤＢ２−１１内の情報は、定期的に転送制御機能部２−３のメモリ内の情報に更新される。転送制御機能部２−３は、この情報を用いて、サービスコンポーネントに応じて、認証、認可、ＩＤ変換の処理のうち、必要な処理のみを行った後に、メッセージプロキシ機能部２−２を介して、実体サービスコンポーネントにサービス利用要求を転送する。これは、認証、認可、ＩＤ変換が必要かどうかは、サービスコンポーネントにより異なるためである。すなわち、認可などが不要で誰でも利用してよいサービスコンポーネントもあれば、そうでないサービスコンポーネントもある。そのため、転送制御機能部２−３は、サービスコンポーネント情報ＤＢ２−１１に保持されている、認証、認可、ＩＤ変換の必要可否情報に応じて、必要な処理（認証、認可、ＩＤ変換）を行うことで、無駄な処理を省いている。

なお、図３及び上述した説明では、認可情報からＩＤ変換機能部２−９を呼び出すとしたが、認可が終了した場合、転送制御機能部２−３に一度返し、転送制御機能部２−３からＩＤ変換機能部２−９を呼び出すように、図５に示すような構成としてもよい。図５では、転送制御機能部２−３とＩＤ変換機能部２−９とが接続され、認可が終了した場合、転送制御機能部２−３に一度返し、転送制御機能部２−３からＩＤ変換機能部２−９を呼び出すよう構成されている点で、図２に示す構成と異なる。

（サービス認証・認可処理）
次に、本実施形態による認証チケット発行時のサービス認証・認可処理について説明する。図６は、本実施形態による認証チケット発行時のサービス認証・認可処理を説明するための概念図である。なお、以下では、サービスリクエスタＡが、サービスコンポーネントａを利用する場合を想定する。

まず、サービスリクエスタ端末５（サービスリクエスタＡ）は、サービス管理機能部２の認証要求受付部２−１、または他認証局６に認証要求を行う（ＳＡ１）。認証要求には、サービスリクエスタ識別子と、パスワードや、生体情報、証明書などの個人識別情報が含まれる。認証要求受付部２−１は、受け取った情報を認証機能部２−４に渡し（ＳＡ２）、認証機能部２−４は、認証用ＤＢ２−６に問い合わせて照合を行うことで認証を判定し（ＳＡ３）、その結果を認証要求受付部２−１に渡す。このとき、認証機能部２−４は、認証が成功した場合には、認証チケットを発行し、また、認証情報をメモリにキャッシュする（ＳＡ４）。認証要求受付部２−１は、認証が成功した場合には、成功という情報と認証チケットとをサービスリクエスタ端末５（のサービスリクエスタＡ）に返し、一方、認証が失敗した場合には、失敗通知のみをサービスリクエスタ端末５（のサービスリクエスタＡ）に返す（ＳＡ５）。認証チケットが発行された場合、サービスリクエスタ端末５は、サービスを利用することになる。一方、他認証局６の場合にも同様の処理が行われ、認証チケットが発行される（ＳＡ６）。

次に、図７は、本実施形態による、認証チケット発行時のサービス管理機能部２の動作を説明するためのフローチャートである。サービス管理機能部２では、認証要求受付部２−１が、サービスリクエスタ端末５からの認証要求を受信すると（ステップＳａ１）、認証要求受付部２−１は、受け取った情報を認証機能部２−４に渡し、認証機能部２−４は、認証用ＤＢ２−６にアクセスし（ステップＳａ２）、ユーザ認証処理を行い（ステップＳａ３）、その結果を認証要求受付部２−１に渡す。このとき、認証機能部２−４は、認証が成功した場合には、認証チケットを発行し、また、認証情報をメモリにキャッシュする（ステップＳａ４）。認証要求受付部２−１は、認証が成功した場合には、成功という情報と認証チケットとをサービスリクエスタ端末５（のサービスリクエスタＡ）に返し、一方、認証が失敗した場合には、失敗通知のみをサービスリクエスタ端末５（のサービスリクエスタＡ）に返す（ステップＳａ５）。

次に、図８は、本実施形態による、ログアウト処理時のサービス管理機能部２の動作を説明するためのフローチャートである。サービス管理機能部２では、認証要求受付部２−１が、サービスリクエスタ端末５からのログアウト要求を受信すると（ステップＳｂ１）、キャッシュしていた認証情報を消去し（Ｓｂ２）、ログアウト結果をサービスリクエスタ端末５に送信する（ＳＳｂ３）。

次に、図９及び図１０は、本実施形態による、認証チケット発行時のシステムの動作を説明するためのシーケンス図である。まず、サービスリクエスタ端末５（サービスリクエスタＡ）は、サービス管理機能部２に認証要求を行う（ＳＳ１）。サービス管理機能部２では、サービスリクエスタ端末５からの認証要求を受信し（ＳＳ２）、認証用ＤＢ２−６にアクセスし（ＳＳ３）、ユーザ認証処理を行い（ＳＳ４）、認証が成功した場合には、認証チケットを発行し、また、認証情報をメモリにキャッシュする（ＳＳ５）。次に、サービス管理機能部２は、認証が成功した場合には、成功という情報と認証チケットとをサービスリクエスタ端末５（のサービスリクエスタＡ）に返し、一方、認証が失敗した場合には、失敗通知のみをサービスリクエスタ端末５（のサービスリクエスタＡ）に返す（ＳＳ６、ＳＳ７）。サービスリクエスタ端末５は、認証チケットが発行された場合、サービスを利用することになる。

次に、サービス利用が終了すると、サービスリクエスタ端末５は、サービス管理機能部２にログアウト要求を行う（ＳＳ８）。サービス管理機能部２は、ログアウト要求を受信すると（ＳＳ９）、キャッシュしていた認証情報を消去し（ＳＳ１０）、ログアウト結果をサービスリクエスタ端末５に送信する（ＳＳ１１、ＳＳ１２）。

また、サービスリクエスタ端末５（サービスリクエスタＡ）が、他認証局６に認証要求を行った場合には（ＳＳ２０）、他認証局６は、サービスリクエスタ端末５からの認証要求を受信し（ＳＳ２１）、認証用ＤＢにアクセスし（ＳＳ２２）、ユーザ認証処理を行い（ＳＳ２３）、認証が成功した場合には、認証チケットを発行し（ＳＳ２４）、認証が成功した場合には、成功したという情報と認証チケットとを、認証が失敗した場合には、失敗通知のみをサービスリクエスタ端末５（のサービスリクエスタＡ）に送信する（ＳＳ２５、ＳＳ２６）。サービスリクエスタ端末５は、認証チケットが発行された場合、サービスを利用することになる。次に、サービス利用が終了すると、サービスリクエスタ端末５は、他認証局６にログアウト要求を行う（ＳＳ２７）。他認証局６は、ログアウト要求を受信すると（ＳＳ２８）、ログアウト結果をサービスリクエスタ端末５に送信する（ＳＳ２９、ＳＳ３０）。

次に、本実施形態によるサービス利用要求処理について説明する。
図１１は、本実施形態によるサービス利用要求処理を説明するための概念図である。図において、サービスリクエスタ端末５（サービスリクエスタＡ）は、サービス管理機能部２の認証要求受付部２−１に、発行された認証チケットを付与してサービス利用要求を送信する（ＳＢ１）。サービス利用要求は、メッセージプロキシ機能部２−２により、中身を解析され、転送制御機能部２−３に供給される（ＳＢ１）。転送制御機能部２−３は、サービス利用要求を転送してよいか判定するために、以下で説明するように、認証機能部２−４、及び認可機能部２−７に問い合わせる（ＳＢ３、ＳＢ４）。なお、前述したように、サービスコンポーネントによっては、認証、認可が必要ない場合もあるため、その場合にはスキップする。

転送制御機能部２−３は、まず、認証機能部２−４に認証確認依頼を行うため、認証チケットを認証機能部２−４に供給する（ＳＢ３）。認証機能部２−４は、認証チケットを自らが発行した場合には、キャッシュされた認証情報と照合して、認証確認を行う。一方、他認証局の発行チケットの場合には、他認証問合機能部２−５に供給して認証正当性を確認し（ＳＢ４、ＳＢ５）、あるいは、信頼できる場合には、正当な認証であると判断する。認証機能部２−４は、認証結果を転送制御機能部２−３に返す（ＳＢ６）。他認証局問合せを行う場合には、他認証局問合機能部２−５は、認証チケット発行者に問い合わせを行い、他認証局が正当に認証したかどうかを確認する（ＳＢ７、ＳＢ８）。

次に、転送制御機能部２−３は、認可機能部２−７に認可依頼を行う（ＳＢ９）。認可機能部２−７は、認証後１回目の利用要求の際には、認可用ＤＢ２−８から、そのサービスリクエスタがどのサービスコンポーネントを現在利用してよいかの情報を取得し、それをキャッシュし、その情報と照合することで、サービス利用要求を転送してよいかを確認する。このとき、ＩＤ変換用ＤＢ２−１０からＩＤ変換情報も取得され、ＩＤ変換機能部２−９にキャッシュされる（ＳＢ１０）。また、認証後２回目以降の利用要求の際には、既にキャッシュされた情報と照合する。認可が成功した際に、利用要求されたサービスコンポーネントが、ＩＤ変換が必要なコンポーネントである場合には、認可機能部２−７は、ＩＤ変換機能部２−９を呼び出し、認証チケットに記述されたサービスリクエスタＩＤを、サービスコンポーネントを利用する際のＩＤに変換させる。

認可機能部２−７から呼び出されたＩＤ変換機能部２−９は、キャッシュされたＩＤ変換情報を用いて、認証チケットのサービスリクエスタ識別子を、サービスコンポーネントを利用する際に必要とされる識別子に変換し、認可機能部２−７に返す。これらが終了した後に、認可機能部２−７は、認可の成功、失敗の結果を転送制御機能部２−３に返す（ＳＢ１１）。認可が成功し、かつ、ＩＤ変換が必要なコンポーネントであった場合には、この時点でＩＤが変換されている。

転送制御機能部２−３は、認可、ＩＤ変換が正しく終了すると、サービス利用要求を、サービスコンポーネントに転送してよいと判定するため、メッセージプロキシ機能部２−２にサービス利用要求を転送するよう指示する一方、正しく終了しなかった場合には、メッセージプロキシ機能部２−２に失敗原因を通知する（ＳＢ１２）。メッセージプロキシ機能部２−２は、サービス利用要求を実体のサービスコンポーネントに転送するか（ＳＢ１３）、あるいは、サービスリクエスタに認証、認可、ＩＤ変換のどこかでエラーが生じたことを通知する。

サービスコンポーネントは、何らかの処理を行い、必要に応じてその結果を、サービスリクエスタに返す。結果を返す際には、サービスリクエスタに直接返してもよいし、メッセージプロキシ機能部２−２を介して返してもよい。一般的なプロキシシステムでは、メッセージプロキシ機能部２−２を介することが多いが、直接返してもよい。

サービスリクエスタ端末５は、利用が終了すると、認証要求受付機能部２−１または他認証局６にログアウト要求を行い、それぞれログアウト処理が行われる。なお、認証チケットには、有効期限があるため、ログアウトは必須ではない。

次に、図１２及び図１３は、本実施形態による、サービス利用要求処理時のサービス管理機能部２の動作を説明するためのフローチャートである。サービス管理機能部２では、認証要求受付部２−１が、サービスリクエスタ端末５（サービスリクエスタＡ）から、発行された認証チケットが付与されたサービス利用要求を受信すると（ステップＳｃ１）、メッセージプロキシ機能部２−２により、中身を解析され、転送制御機能部２−３に情報を通知する（ステップＳｃ２）。

転送制御機能部２−３は、サービス利用要求を転送してよいか判定するために、認証機能部２−４に認証確認依頼を行う（ステップＳｃ３）。認証機能部２−４は、認証情報がキャッシュされているか否かを判定し（ステップＳｃ４）、キャッシュされていない場合には、他認証問合機能部２−５に供給して認証正当性を確認するか、あるいは、信頼できる場合には、正当な認証であると判断し（ステップＳｃ５）、認証情報をキャッシュし（ステップＳｃ６）、認証確認を行う（ステップＳｃ７）。一方、認証機能部２−４は、認証チケットを自らが発行した場合には、認証情報がキャッシュされているので、キャッシュされた認証情報と照合して、認証確認を行い（ステップＳｃ７）、認証結果を転送制御機能部２−３に通知する（Ｓｃ８）。

次に、転送制御機能部２−３は、認可機能部２−７に認可依頼を行う（Ｓｃ９）。認可機能部２−７は、認可情報がキャッシュされているか否かを判定し（ステップＳｃ１０）、キャッシュされていない場合には、認可用ＤＢ２−８から、そのサービスリクエスタがどのサービスコンポーネントを現在利用してよいかの認可情報を取得し、それをキャッシュし（ステップＳｃ１１）、さらに、ＩＤ変換用ＤＢ２−１０からＩＤ変換情報を取得してＩＤ変換機能部２−９にキャッシュし（Ｓｃ１２）、その情報と照合することで、サービス利用要求を転送してよいかを確認する（Ｓｃ１３）。一方、認証後２回目以降の利用要求の際には、既にキャッシュされた情報と照合する（Ｓｃ１３）。

次に、認可機能部２−７は、利用要求されたサービスコンポーネントが、ＩＤ変換が必要なコンポーネントであるか否かを判定し（ステップＳｃ１４）、ＩＤ変換が必要なコンポーネントである場合には（ステップＳｃ１４のＹＥＳ）、認可機能部２−７は、ＩＤ変換機能部２−９を呼び出し、ＩＤ変換を依頼し（ステップＳｃ１５）、認証チケットのサービスリクエスタ識別子を、サービスコンポーネントを利用する際に必要とされる識別子に変換させる（Ｓｃ１６）ＩＤ変換機能部２−９は、キャッシュされたＩＤ変換情報を用いて、認証チケットのサービスリクエスタ識別子を、サービスコンポーネントを利用する際に必要とされる識別子に変換し、認可機能部２−７に通知する（Ｓｃ１７）。その後、認可機能部２−７は、認可の成功、失敗の結果を転送制御機能部２−３に通知する（Ｓｃ１８）。一方、ＩＤ変換が不要である場合には（ステップＳｃ１４のＮＯ）、ＩＤ変換せずに、直接、認可の成功、失敗の結果を転送制御機能部２−３に通知する（Ｓｃ１８）。

次に、転送制御機能部２−３は、認可、ＩＤ変換が正しく終了すると、サービス利用要求を、サービスコンポーネントに転送してよいかを判定するため、メッセージプロキシ機能部２−２にサービス利用要求を転送するよう指示する一方、正しく終了しなかった場合には、メッセージプロキシ機能部２−２に失敗原因を通知する（Ｓｃ１９）。メッセージプロキシ機能部２−２は、サービス利用要求を実体のサービスコンポーネントに転送する（Ｓｃ２０）。

次に、図１４乃至図１６は、本実施形態による、サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。まず、サービスリクエスタ端末５（サービスリクエスタＡ）は、サービス管理機能部２に、発行された認証チケットを付与してサービス利用要求を送信する（ＳＴ１）。サービス管理機能部２では、サービスリクエスタ端末５（サービスリクエスタＡ）から、発行された認証チケットが付与されたサービス利用要求を受信し（ステップＳＴ２）、転送制御機能部２−３に情報を通知し（ステップＳＴ３）、サービス利用要求を転送してよいか判定するために、認証機能部２−４に認証確認依頼を行う（ステップＳＴ４）。

次に、認証情報がキャッシュされているか否かを判定し（ステップＳＴ５）、キャッシュされていない場合には、他認証局に問い合わせるか、あるいは、他認証局６に認証確認を依頼して認証結果を取得するか、信頼できる場合には、正当な認証であると判断し（ＳＴ６）、認証情報をキャッシュし（ステップＳＴ７）、認証確認を行う（ステップＳＴ８）。一方、認証チケットを自らが発行した場合には、認証情報がキャッシュされているので、キャッシュされた認証情報と照合して、認証確認を行う（ステップＳＴ８）。いずれの場合も、その後、認証結果を転送制御機能部２−３に通知する（ＳＴ９）。

次に、サービス管理機能部２では、転送制御機能部２−３が認可機能部２−７に認可依頼を行い（ＳＴ１０）。認可機能部２−７は、認可情報がキャッシュされているか否かを判定し（ステップＳＴ１１）、キャッシュされていない場合には、認可用ＤＢ２−８から認可情報を取得し、それをキャッシュし（ステップＳＴ１２）、ＩＤ変換用ＤＢ２−１０からＩＤ変換情報を取得してＩＤ変換機能部２−９にキャッシュし（ＳＴ１３）、その情報と照合することで、サービス利用要求を転送してよいかを確認する（ＳＴ１４）。一方、キャッシュされている場合には、既にキャッシュされた情報と照合し、サービス利用要求を転送してよいかを確認する（ＳＴ１４）。

次に、利用要求されたサービスコンポーネントが、ＩＤ変換が必要なコンポーネントであるか否かを判定し（ステップＳＴ１５）、ＩＤ変換が必要なコンポーネントである場合には（ステップＳｃ１４のＹＥＳ）、認可機能部２−７は、ＩＤ変換機能部２−９を呼び出し、ＩＤ変換を依頼し（ステップＳＴ１６）、認証チケットのサービスリクエスタ識別子を変換し（ＳＴ１７）、認可機能部２−７に通知する（ＳＴ１８）そして、認可の成功、失敗の結果を転送制御機能部２−３に通知する一方、ＩＤ変換が不要である場合には、ＩＤ変換せずに、直接、認可の成功、失敗の結果を転送制御機能部２−３に通知する（ＳＴ１９）。

次に、サービス利用要求を、メッセージプロキシ機能部２−２にサービス利用要求を転送するよう指示し、メッセージプロキシ機能部２−２は、サービス利用要求を実体のサービスコンポーネント提供端末３に転送する（ＳＴ２１、ＳＴ２２）。これに対して、サービスコンポーネント提供端末３からサービス応答があると、それをサービスリクエスタ端末に返す（ＳＴ２２、ＳＴ２３）。なお、サービス利用要求に対する応答がある場合には、サービス管理機能部２を介して、サービスリクエスタ端末５に応答してもよいし、直接、サービスリクエスタ端末５に返してもよい。

上述したように、１つのサービスコンポーネントａを１回利用する場合には、サービスリクエスタ端末５は、認証チケットの発行時に認証を行い、また、認可時も認可用ＤＢ２−８にアクセスするため、サービス管理機能部２を用いる利点はそれほど大きくない。

（複数のサービスコンポーネントの利用）
次に、サービスリクエスタ端末５（サービスリクエスタＡ）が、サービスコンポーネントａ、ｂ、ｃを順番に利用する場合を想定する。認証チケットは、一定期間は有効であるため、サービスリクエスタ端末５（サービスリクエスタＡ）は、認証チケットをａ、ｂ、ｃへの利用要求の際に繰り返し用いることで、認証チケットを何回も発行してもらう必要はない。また、サービスコンポーネントａを利用後、サービスコンポーネントｂ、ｃを利用する場合には、サービス管理機能部２の認可機能部２−４や、ＩＤ変換機能部２−９に、既に、認可情報や、ＩＤ変換情報がキャッシュされているため、認可時も認可用ＤＢ２−８にアクセスする必要がないので、高速の認可処理が可能となる。さらに、３つのサービスコンポーネントを利用する際のＩＤ体系が異なっていても、サービス管理機能部２がＩＤ変換を行うため、異なるＩＤで何回も認証する必要がない。

（連携サービス利用要求処理）
さらに、サービスリクエスタ端末５（サービスリクエスタＡ）が、連携サービスを実行するサービスコンポーネントｄ（連携サービスシナリオ実行端末４が提供）を利用する場合について説明する。連携サービス実行コンポーネントとしては、例えば、Ｗｅｂサービスを複数連携した連携サービスを１つのＷｅｂサービスに見せるＢＰＥＬサービスがある。

図１７は、本実施形態による、連携サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。なお、連携サービスシナリオ実行端末４（サービスコンポーネントｄ）が、サービスコンポーネントａ、ｂ、ｃを連携して実行するとする。この場合、Ａ→ｄのリクエスト時は（ＳＵ１、ＳＵ２、ＳＵ３）、サービスコンポーネントｄは、コンポーネントとして動作し、ｄ→ａ（ＳＵ４〜ＳＵ８）、ｄ→ｂ（ＳＵ９〜ＳＵ１２）、ｄ→ｃ（省略）の際には、リクエスタとして動作する。なお、サービス利用要求に対する応答がある場合には、サービス管理機能部２を介して、連携サーバシナリオ実行端末４に返してもよいし、直接、連携サービスシナリオ実行端末４に返してもよい（ＳＵ７、ＳＵ８、ＳＵ１２、ＳＵ１３）。また、サービスリクエスタ端末５のサービス利用要求に対する応答がある場合には、サービス管理機能部２を介して、サービスリクエスタ端末５に応答してもよいし、直接、サービスリクエスタ端末５に返してもよい（ＳＵ１４、ＳＵ１１５）。以下、より具体的に説明する。

サービスコンポーネントｄがリクエスタとして動作するためには、サービスコンポーネントａ、ｂ、ｃを呼ぶ際の認証チケットが必要である。そのため、サービスコンポーネントｄは、サービスコンポーネントＤＢに認証チケットを引き継ぐ形で設定されている。さらに、サービスコンポーネントｄのサービスシナリオ上には、サービスコンポーネントａ、ｂ、ｃを呼び際にサービス管理機能部２から引き継がれて受け取った認証チケットを付与するというシナリオが記述されている。このようにすることで、Ａ→ｄへのリクエスト時は、認証チケット情報がサービスコンポーネントｄに引き渡され、サービスコンポーネントｄのシナリオ内で受け取った認証チケットを、ａ、ｂ、ｃを呼び際にコピーするようになっているため、ｄ→ａ、ｄ→ｂ、ｄ→ｃでも認証チケットが渡される。

このように、サービスリクエスタ端末５（サービスリクエスタＡ）が１つの連携サービスを呼び出し、連携サービスから複数のサービスコンポーネントを呼び出す場合でも、サービスリクエスタ端末５（サービスリクエスタＡ）は、１回の認証で、連携サービスを利用することができる。また、Ａ→ｄ時に認可用ＤＢ２−８へのアクセスが終了しているため、ｄ→ａ、ｄ→ｂ、ｄ→ｃでは、認可を高速に行うことができる。

なお、本発明は、図を用いて説明した形態に限定されるものでなく、その主旨を逸脱しない範囲において種々変更可能である。

上述した実施形態によれば、サービスコンポーネントを連携してサービス利用する際に、サービスリクエスタは、１回の認証で、複数のサービスコンポーネントを連携利用できるようになるため、手間を軽減することができる。また、サービスコンポーネント提供者は、認証、認可などの共通処理を行う必要がなくなるため、サービスコンポーネント作成コストを削減することができる。また、サービスコンポーネント管理者は、既存製品である、認証を行う製品、認可を行う製品、識別子変換を行う製品等を購入し、それらを連携させて動作せるのに比べて、認証認可情報を同一マシンのメモリにキャッシュして利用することで、共通処理の高速化を図ることができる。

なお、上述したサービス管理機能部２における各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、符号化処理、及び復号化処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

本発明の実施の形態におけるシステムの構成例を示すブロック図である。 本実施形態による、サービスリクエスタ端末５、サービスコンポーネント提供端末３、サービス管理機能部２、連携サービスシナリオ実行端末４の関係を示すブロック図である。 本実施形態によるサービス管理機能部２の構成を示すブロック図である。 ＩＤ変換、ＩＤ削除、ＩＤ引き継ぎの３つのパターンを示す概念図である。 本実施形態によるサービス管理機能部２の変形例の構成を示すブロック図である。 本実施形態による認証チケット発行時のサービス認証・認可処理を説明するための概念図である。 本実施形態による、認証チケット発行時のサービス管理機能部２の動作を説明するためのフローチャートである。 本実施形態による、ログアウト処理時のサービス管理機能部２の動作を説明するためのフローチャートである。 本実施形態による、認証チケット発行時のシステムの動作を説明するためのシーケンス図である。 本実施形態による、認証チケット発行時のシステムの動作を説明するためのシーケンス図である。 本実施形態によるサービス利用要求処理を説明するための概念図である。 本実施形態による、サービス利用要求処理時のサービス管理機能部２の動作を説明するためのフローチャートである。 本実施形態による、サービス利用要求処理時のサービス管理機能部２の動作を説明するためのフローチャートである。 本実施形態による、サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。 本実施形態による、サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。 本実施形態による、サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。 本実施形態による、連携サービス利用要求処理時のシステムの動作を説明するためのシーケンス図である。

符号の説明

１ ネットワーク
２ サービス管理機能部
３ サービスコンポーネント提供端末
４ 連携サービスシナリオ実行端末
５ サービスリクエスタ端末
６ 他認証局
２−１ 認証要求受付機能部
２−２ メッセージプロキシ機能部
２−３ 転送制御機能部
２−４ 認証機能部
２−５ 他認証局問合機能部
２−６ 認証用ＤＢ
２−７ 認可機能部
２−８ 認可用ＤＢ
２−９ ＩＤ変換機能部
２−１０ ＩＤ変換用ＤＢ
２−１１ サービスコンポーネント情報ＤＢ

Claims (9)

1. サービスリクエスタ端末からのサービスリクエスタに対して、単数のサービスコンポーネントの利用もしくは複数のサービスコンポーネントを連携して利用可能にする際に、個々のサービスコンポーネントの認証、認可を行うサービス管理方法であって、
   前記サービスリクエスタ端末からの認証要求に基づいて認証を行うステップと、
   前記認証が正当に行われると、前記サービスリクエスタ端末に対して認証チケットを発行するステップと、
   前記サービスリクエスタ端末のサービスコンポーネント利用時に送信するサービス利用要求に付与されている前記認証チケットの正当性を認証するステップと、
   前記認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかの認可を行うステップと、
   前記サービスコンポーネントの利用が認可された場合、当該サービス利用要求をサービスコンポーネントに転送するステップと、
   を含むことを特徴とするサービス管理方法。
2. 前記認証または認可のいずれかに問題があった場合、前記サービス利用要求の要求エラーを前記サービスリクエスタ端末に転送するステップをさらに含むことを特徴とする請求項１記載のサービス管理方法。
3. 前記認証は、パスワード、生体情報、証明書のいずれかを用いて照合することで行うことを特徴とする請求項１記載のサービス管理方法。
4. 前記認証チケットは、少なくとも、サービスリクエスタ識別子と、発行した認証局の認証情報とを含むことを持徴とする請求項１記載のサービス管理方法。
5. 前記認証チケット発行時にサービスリクエスタ端末の認証情報を第１の記憶手段に保持するステップと、
   前記サービスリクエスタ端末からサービス利用要求があった際には、前記サービス利用要求に付与された認証チケットが正当であるかを、前記第１の記憶手段に保持された認証情報と比較して確認するステップと
   をさらに含むことを特徴とする請求項１乃至４のいずれかに記載のサービス管理方法。
6. 前記認証チケットが他の認証局により発行されたものであった場合、正しく認証されたかどうかを、前記他の認証局に問い合わせるステップと、
   前記認証チケットの正当性が認証された場合、該当認証情報を前記第１の記憶手段に保持するステップとをさらに含み、
   前記サービスリクエスタ端末から同じサービス利用要求が再度あった際には、前記サービス利用要求に付与された認証チケットが正当であるかを、前記第１の記憶手段に保持された認証情報と比較して確認することを特徴とする請求項５に記載のサービス管理方法。
7. 前記認可の正当性が確認された場合、サービス利用要求に対応する認可情報を第２の記憶手段に保持するステップと、
   前記サービスリクエスタ端末から、再度同じサービスコンポーネント利用要求または異なるサービスコンポーネント利用要求があった際に、かつ該サービス利用要求に付与された認証チケットの正当性が認証された場合に、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかを、前記第２の記憶手段に保持された認可情報と比較して確認するステップと、
   をさらに含むことを特徴とする請求項１乃至４のいずれかに記載のサービス管理方法。
8. 前記認証・認可の正当性が確認された場合、サービス利用要求転送前に、前記認証チケットに記載されたサービスリクエスタ識別情報を、実際のサービスコンポーネントで用いられるサービスコンポーネント識別情報に変換するステップをさらに含むことを特徴とする請求項１乃至７のいずれかに記載のサービス管理方法。
9. サービスリクエスタ端末からのサービスリクエスタに対して、単数のサービスコンポーネントの利用もしくは複数のサービスコンポーネントを連携して利用可能にする際に、個々のサービスコンポーネントの認証、認可を行うサービス管理システムであって、
   前記サービスリクエスタ端末からの認証要求に基づいて認証を行う認証要求受付手段と、
   前記認証受付手段により認証が正当に行われると、前記サービスリクエスタ端末に対して認証チケットを発行する認証チケット発行手段と、
   前記サービスリクエスタ端末のサービスコンポーネント利用時に送信するサービス利用要求に付与されている前記認証チケットの正当性を認証する認証手段と、
   前記認証手段により認証チケットの正当性が認証された場合、当該サービス利用要求に該当するサービスコンポーネントを利用してよいかの認可を行う認可手段と、
   前記認可手段によりサービスコンポーネントの利用が認可された場合、当該サービス利用要求をサービスコンポーネントに転送する転送制御手段と、
   を備えることを特徴とするサービス管理システム。

Images