JP2007257139A - 秘密保持が要求されるモデルの認証設定のための情報処理装置 - Google Patents

Abstract

【課題】サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発するサービス開発者が当該サービスモデルのための認証設定を行い易くする情報処理装置等を提供する。
【解決手段】サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発する情報処理装置であって、サービスにおいて、サービスに関する注釈を入力する入力手段と、サービスが実行されるマシン・ノードの認証基盤モデルを記憶する記憶部と、注釈と前記認証基盤モデルより認証ポリシーを生成する認証ポリシー生成部と、を備える情報処理装置等を提供する。
【選択図】図２

Description

本発明は、サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発するサービス開発者が当該サービスモデルのための認証設定を行い易くする情報処理装置、ソフトウエア開発方法、およびそのコンピュータプログラムに関する。

インターネットの普及にともない、Ｗｅｂを使用して電子商取引等を行うシステムが増大している。これらのシステムでは個人情報、パスワード、お金に関する情報など秘密を確保しなければならない情報がある。

また、サービス指向アーキテクチャ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｔｅｃｔｕｒｅ）の考え方が広がるにつれ、ネットワーク上に点在するサービスを組み合わせることによりさらに高度なサービスとして利用されることが多くなってきた。

これらの従来技術としては、Ｗｅｂを使用して電子商取引等を行うサービスに関しては、ＷｅｂＳｐｈｅｒｅ Ａｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＷＡＳ）（登録商標）でＷＳ−Ｓｅｃｕｒｉｔｙ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｓｅｃｕｒｉｔｙ）が利用可能である。ＷＳ−Ｓｅｃｕｒｉｔｙでは、ＷｅｂサービスでやりとりされるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージを保護するために、メッセージに署名を付加したり、メッセージを暗号化したり、認証のための情報を付け加えたりする方法を定義している。ＷＳ−Ｓｅｃｕｒｉｔｙについては、非特許文献１に紹介されている。

また、これらのサービス開発に際してはＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）が使用されることが多い。ＵＭＬに関しては非特許文献２に紹介されている。

加藤 健二、外４名、"Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｓｅｃｕｒｉｔｙ." ２００２年５月２３日 Ｍｉｃｒｏｓｏｆｔ ｈｏｍｅ ｐａｇｅ 平成１７年１０月２８日検索、インターネット＜ＵＲＬ：http://www.microsoft.com/japan/msdn/webservices/spec/ws-security.asp＞ 株式会社テクノロジックアート著「ＵＭＬモデリングＬ１」株式会社翔泳社発行４６ページから６３ページ、２２４ページから２２８ページ

しかし、ネットワーク上に点在するサービスの組み合わせによる高度なサービスの開発を行う場合に、それぞれのサービスは異なったセキュリティ基盤上で動いてくることも多いので、一般にセキュリティの設定は難しくなる。

また、本発明で扱う認証設定に関しても、認証機構やセキュリティ・ドメインの違いなどを十分に理解してないと、正しく設定することはできない。特に、現実のプロジェクトでは、このような高度に専門的な知識が必要にもかかわらず、開発期間や予算などの関係で、サービス開発者がセキュリティを設定しなければならないケースが多い。

さらに、開発するサービスに認証機能を設定するには、そのサービスに必要なセキュリティポリシーを定義する必要がある。
ＷＳ−Ｓｅｃｕｒｉｔｙの場合、セキュリティポリシーを正確に定義するには高度なスキルが必要であり、同時に開発するサービスが動作するマシン・ノードが提供している機能を正しく理解していないと、適切なセキュリティポリシーを作成することはできない。サービスにどういった認証機能が必要かということは、サービス開発者が設定するが、サービス開発者自身がマシン・ノードに依存したセキュリティの詳細設定を行うのは非常に困難である。

従って、本発明は上記課題を解決するために、サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発するサービス開発者が当該サービスモデルのための認証設定を行い易くする情報処理装置、ソフトウエア開発方法、およびそのコンピュータプログラムを提供することを目的とする。

上記課題を解決するために、本発明の第１の形態においては、サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発する情報処理装置であって、サービスにおいて、サービスに関する注釈を入力する入力手段と、サービスが実行されるマシン・ノードの認証基盤モデルを記憶する記憶部と、注釈と前記認証基盤モデルより認証ポリシーを生成する認証ポリシー生成部と、を備える情報処理装置を提供する。

また、本発明の第２の形態においては、サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発するソフトウエア開発方法であって、サービスにおいて、サービスに関する注釈を入力する入力ステップと、サービスが実行されるマシン・ノードの記憶されている認証基盤モデルを読み出すステップと、注釈と認証基盤モデルより認証ポリシーを生成する認証ポリシー生成ステップと、を備えるソフトウエア開発方法、およびそのコンピュータプログラムを提供する。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりえる。

〔用語の定義〕
認証ポリシー（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｏｌｉｃｙ）とは、必要とされるユーザＩＤの形式、認証のための機構、セキュリティ・ドメインなど、技術的な詳細を含んだものである。
認証基盤モデル（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｍｏｄｅｌ、ＡＩＭ）とは、認証に関する特徴的な側面をモデル化したものであり、身分証明の伝播、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ、ＳＳＯ）、サービス間の信頼関係（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｌａｔｉｏｎ）などの情報が表現されている。
身分証明（Ｉｄｅｎｔｉｆｙ、ＩＤ）とは、誰であるかを明らかにすることをいう。

本発明によって、認証基盤モデルを用いることにより、サービスモデル上での簡略な注釈表現から、複雑な認証基盤に対応した認証ポリシーを生成することができる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、本発明の考え方を示す概念図であり、図２は、本発明の情報処理装置の構成を示す図である。図３は、本発明の実施例である認証ポリシーの形式を示す図である。図４は、本発明の実施例である認証ポリシーの内部データ構造を示す図である。図５は、本発明の実施例である認証基盤モデルのデータ構造を示す図である。図６は、本発明のソフトウエア開発方法のアルゴリズムの概要を示す図である。以下本発明の概念と構成について、図１から図６を参照して説明をする。

図１に示すように、注釈設定用グラフィカルエディタにより、サービス開発者はサービスをモデル化したものを編集できる。サービスモデルはサービスを組み合わせたものとなっており、各サービスに対して、認証という注釈を入れることができる。認証ポリシー生成部は、認証に関する注釈と認証基盤モデルから、認証ポリシーを生成するものである。

認証基盤モデルは、サービスを実行する環境で提供される認証基盤に基づいており、図１にあるように実行環境からのモデル抽出によって得られる。なお、モデル抽出そのものは重要な問題であるが、本発明の範囲外であるので破線矢印で示してある。また、生成された認証ポリシーは実行環境へと配備される。ここで、配備そのものは通常の商用製品でも提供されている機能であるので、説明を省略する。

図２は、本発明の情報処理装置１００の構成を示す図である。情報処理装置１００は、後で詳細に説明する図１６のハードウエア上で動作するオペレーティングシステム６０と、オペレーティングシステム６０上で動作するサービスに関する注釈を入力する入力手段１１５と、注釈設定用グラフィカルエディタ１２０と、サービスが実行されるマシン・ノードの認証基盤モデル２００と、注釈と認証基盤モデル２００より認証ポリシーを生成する認証ポリシー生成部３００と、生成された認証ポリシー４００と、認証基盤モデル２００と生成された認証ポリシー４００が記憶される記憶部１（２２０）と、記憶部２（４２０）を備える。なお、記憶部１（２２０）と、記憶部２（４２０）とは１つの記憶部に記憶場所を区切って使用することもできる。サービス指向アーキテクチャにおいて秘密保持が要求されるサービスであるサービス１１０は、情報処理装置１００の入力手段１１５に必要な注釈を入力し注釈設定用グラフィカルエディタ１２０に注釈を付することにより複雑な認証基盤に対応したサービスを開発することができる。

図３は、本発明の実施例である認証ポリシーの形式を示す図である。図３はＷＳ−Ｓｅｃｕｒｉｔｙに従って記載されている（非特許文献１参照）。認証ポリシーについてプログラム上で簡易的に定義したものである。ここで、各要素は次の通りである。
１行目のＡｕｔｈｅｎｔｉｃａｔｉｏｎは、認証ポリシーに認証情報を埋め込むためのトップレベルの要素である。
２行目のＣａｌｌｅｒＴｏｋｅｎは、認証に関する具体的な情報を入れるためのトップレベルの要素である。
３行目以降の＄｛ＴＯＫＥＮ ＡＳＳＥＲＴＩＯＮ｝は、ＩＤに関する情報を符号化したものをトークンと呼ぶ。トークンには様々な種類があり、ここにはトークンの種類を書く。実際の中味に関しては、ＷＳ−ＳｅｃｕｒｉｔｙＰｏｌｉｃｙ規格｛｝で定義されているものを使う。ＵｓｅｒｎａｍｅＴｏｋｅｎの場合は、単に＜ＵｓｅｒｎａｍｅＴｏｋｅｎ＞と書く。

ＳｅｃｕｒｉｔｙＤｏｍａｉｎは、上記、トークンの種類だけでは、トークンを区別するのに十分ではない。これらを区別するための概念がセキュリティ・ドメインである。
ＳｅｃｕｒｉｔｙＤｏｍａｉｎの要素には、ｄｏｍａｉｎＮａｍｅ属性があり、ここにセキュリティ・ドメインの名前を記述する。
ＴｒｕｓｔＭｅｔｈｏｄは、＄｛ＴＯＫＥＮ ＡＳＳＥＲＴＩＯＮ｝で、トークンが認証のための情報を含んでいない場合、別途信頼関係を確立するための方法が必要になる。この要素はｍｅｔｈｏｄ属性により、その種類を特定する。例えば、Ｓｉｇｎａｔｕｒｅはデジタル署名、ＢａｓｉｃはＩＤ／パスワードによる認証になる。

図４は、本発明の実施例である認証ポリシーの内部データ構造を示す図である。なお、図４と図５はＵＭＬモデリングによる記載をしている（非特許文献２参照）。上記の認証ポリシーの構造とほぼ対応しているが、いくつかの追加点がある。ＴｏｋｅｎＡｓｓｅｒｔｉｏｎ４３０（トークン表明）は抽象的なクラスとして定義されており、具体的なトークンに関しては、そのサブクラスとして定義されている。ＴｒｕｓｔＭｅｔｈｏｄ４５０（信頼方法）はＴｏｋｅｎＡｓｓｅｒｔｉｏｎ４３０へとリンクが張られている。

信頼関係の確立には通常は認証が使われるが、その場合は、トークンを必要とする。トークンの種類を特定するために、ＴｏｋｅｎＡｓｓｅｒｔｉｏｎへのリンクが張られている。但し、ＣａｌｌｅｒＴｏｋｅｎが直接持っているＴｏｋｅｎＡｓｓｅｒｔｉｏｎとＴｒｕｓｔＭｅｔｈｏｄから指されるＴｏｋｅｎＡｓｓｅｒｔｉｏｎは異なるものであることに注意が必要である。

図５は、本発明の実施例である認証基盤モデルのデータ構造を示す図である。各要素について以下説明する。
ＴｏｋｅｎＳｔａｔｅｍｅｎｔ（トークン言明）２３０とは、トークン（ＩＤならびにパスワードなどの関連する情報を符号化したもの）に関する言明（Ｓｔａｔｅｍｅｎｔ）を記述するための要素である。対象とするトークンの種類や処理の方法に関しては別の要素で表現しており、この要素自体はＳｕｂｊｅｃｔ（呼出主体）とｓｅｃｕｒｉｔｙＤｏｍａｉｎという２つの属性のみを持っている。Ｓｕｂｊｅｃｔは、ここでのトークンが主要トークン（ｐｒｉｍａｒｙ）であるかを示す真偽値である。ｓｅｃｕｒｉｔｙＤｏｍａｉｎ属性は、トークンが管理されるセキュリティ・ドメインを示すものである。

ＳｅｎｄｅｒＴｒｕｓｔ（送信者信頼法）２２０とは、上記の信頼関係を実現する方法を記述するための要素である。この要素は、ＴｏｋｅｎＳｔａｔｅｍｅｎｔ２３０のＳｕｂｊｅｃｔ属性がｔｒｕｅとなる場合のみ必要になる。ここでは、属性ｍｅｔｈｏｄに認証方法を記述するようになっており、具体的な値にはＳｉｇｎａｔｕｒｅやＢａｓｉｃなどが入る。Ｓｉｇｎａｔｕｒｅとは、送信者をデジタル署名により認証する方法である。ＢａｓｉｃとはＩＤ／Ｐａｓｓｗｏｒｄで認証する方法である。なお、ＳｅｎｄｅｒＴｒｕｓｔ２２０はＴｒｕｓｔＳｔａｔｅｍｅｎｔ要素を持つが、この要素自体は信頼関係を確立するためのものであるので（副次的なトークン）、Ｓｕｂｊｅｃｔ属性はｆａｌｓｅでなければならない。

ＭａｃｈｉｎｅＮｏｄｅ（マシン・ノード）２１０とは、アーキテクチャが実行されるマシン・ノードを表す要素である。各ノードでは受け入れ可能なトークンや、送信可能なトークンがあらかじめ決まっているので、ＴｏｋｅｎＳｔａｔｅｍｅｎｔ２３０へのリンクが張られている。同様に、信頼関係の確立方法に関してもＭａｃｈｉｎｅＮｏｄｅ２１０に固有の情報なので、ＳｅｎｄｅｒＴｒｕｓｔ２２０へとリンクが張られている。図では十分に表現されてないが、ＴｏｋｅｎＳｔａｔｅｍｅｎｔ２３０ならびにＳｅｎｄｅｒＴｒｕｓｔ２２０へのリンクは、送信用と受信用の二種類を区別して設定するようになっている。

ＴｏｋｅｎＰｒｏｃｅｓｓｉｎｇ２６０（トークン処理）とは、トークンを処理する実装に関する情報を抽象化したものである。図５では一例として、ユーザ・レジストリーがつながる様子や、ＴｏｋｅｎＧｅｎｅｒａｔｏｒやＴｏｋｅｎＣｏｎｓｕｍｅｒなどの実装クラスが接続されている。

図６は、本発明のソフトウエア開発方法のアルゴリズムの概要を示す図である。図６に示すように、サービスに関する注釈を入力手段１１５により注釈設定用グラフィカルエディタ１２０用いて入力する（Ｓ１１０）。入力すると注釈つきのサービスモデル１１２が生成される。次に記憶部１（２２０）に記憶されている認証基盤モデル２００を呼び出す（Ｓ１２０）。注釈つきのサービスモデル１１２と読み出された認証基盤モデル２００よりサービスとマシン・ノードの対応付けを行う（Ｓ１３０）。その対応付けに基づいてサービスからノードへの対応関係を明らかにし（Ｓ１４０）、認証ポリシーを生成する（Ｓ１５０）。生成された認証ポリシー４００を記憶部２（４２０）に記憶する。サービス開発者が必要と認める場合は指定すると後述の表示装置１０２２に表示する。

このようにして、サービスモデル上での簡略な注釈表現から、複雑な認証基盤に対応した認証ポリシーを生成することができる。

以上本発明の構成と認証ポリシー生成について説明した。以下本発明の理解がし易いように具体例について説明するとともに本発明の動作について説明する。

図７は、サービスモデルの１例である、旅行代理店のシナリオ、を表す図である。図８は、本発明の認証の具体的な実施例である。図９は、本発明の注釈設定用のグラフィカルエディタの実施例である。図１０と図１１は、本発明の実施例である認証ポリシー生成のフローチャートを示す図である。図１２は、本発明の実施例であるサービスモデルと認証基盤モデルとの対応関係を示す図である。図１３は、本発明の実施例である旅行代理店のデータ構造を示す図である。以下、これらの図を参照して説明する。

図７は、サービスモデルの１例である、旅行代理店のシナリオ、を表す図である。ある顧客が個人旅行を計画しており、旅行代理店に依頼を出す。旅行代理店は、航空会社やホテルチェーンなどに問い合わせて、航空券やホテルの空きぐあいや料金などの情報をまとめて、顧客に結果を返す。顧客は旅行代理店にアクセスする際に、ＩＤとパスワードを入力する。旅行代理店では、顧客に関する情報を管理しており、航空会社やホテルチェーンに問い合わせる際に、顧客の番号（マイレージ番号など）を一緒に送る。これにより、顧客のメンバーシップなどの情報を利用可能になり、例えば、顧客にとってメリットのある航空券を提供することができる。

図８は、本発明の認証の具体的な１実施例である。図８に示すように、顧客はＩＤ／パスワードを旅行代理店に送付する。この際、ＩＤ／パスワードをコード化する方法を指定する必要があり、ここではＷＳ−Ｓｅｃｕｒｉｔｙで定義されているＵｓｅｒｎａｍｅＴｏｋｅｎという形で送付する。例えば、以下のような形である。
＜ＵｓｅｒｎａｍｅＴｏｋｅｎ＞
＜Ｕｓｅｒｎａｍｅ＞ｓｆｕｍｉｋｏ＜／Ｕｓｅｒｎａｍｅ＞
＜Ｐａｓｓｗｏｒｄ＞ｏｋｉｍｕｆｓ＜／Ｐａｓｓｗｏｒｄ＞
＜／ＵｓｅｒｎａｍｅＴｏｋｅｎ＞

旅行代理店は、ＩＤ／パスワードを受け取ると、これを基に顧客を認証しなければならない。ユーザ・レジストリーは、ＩＤを認証するための情報を登録したものであり、ここでは顧客のＩＤ／パスワードが格納されている。

次に、旅行代理店は航空会社に問い合わせをする必要がある。この際、顧客のマイレージ番号を同時に送る必要がある。マイレージ番号は認証した顧客のＩＤに対応している必要があるので、このような処理をＩＤマッピングと呼ぶ。ＩＤマッピングを行うには、ＩＢＭ Ｔｉｖｏｌｉ Ｆｅｄｅｒａｔｅｄ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｒ（登録商標）を使うことができる。

ここでの例では、顧客情報に関するデータベースがあり、そこにマッピングの情報も登録されており、それを使ってＩＤマッピングが行われる。旅行代理店は以下のような形式でマイレージ番号を航空会社に送る。
＜ＵｓｅｒｎａｍｅＴｏｋｅｎ＞
＜Ｕｓｅｒｎａｍｅ＞１２３４５６７＜／Ｕｓｅｒｎａｍｅ＞
＜／ＵｓｅｒｎａｍｅＴｏｋｅｎ＞

このようにパスワードがない場合、航空会社はこの情報からだけでは顧客を認証することができない。そこで、旅行代理店のＩＤ／パスワードも同時に送付する。航空会社は旅行代理店を認証し、認証された旅行代理店が送ってきたマイレージ番号なので、送られてきた情報を信用する。なお、航空会社は、送られてきたマイレージ番号と旅行代理店のＩＤ／パスワードをそれぞれに対応するユーザ・レジストリを使って確認する。ここでユーザ・レジストリとはユーザのデータを記録したファイルである。

図９は、本発明の注釈設定用のグラフィカルエディタの実施例である。本発明の情報処理装置のユーザであるサービス開発者は、図９のように画面に注釈を付けていく。認証の場合、Ａｕｔｈｅｎｔｉｃａｔｉｏｎという要素を追加し、その中のｃａｌｌｅｒ Ｔｙｐｅ属性に値を設定すれば良い。

ここで重要な点は、図９に示すように、顧客から旅行代理店へと、旅行代理店から航空会社への２つのｃａｌｌｅｒＴｙｐｅ属性の値が共にｔｒａｖｅｌｅｒとなっていることである。サービス開発者は図８で示したような認証基盤の詳細を理解できないことが多い、あるいはそのような詳細を気にしたくない。旅行代理店の例では、ＩＤとしては違うものであるが、それらが指す実際の顧客は同一である。したがって、サービス開発者のレベルでは、ＩＤを区別せずに、単にｔｒａｖｅｌｅｒと指定して、概念的には同じものとみなすことができる。このような認証に関する注釈を導入した点が、本発明の特徴の１つである。

図１０と図１１は、本発明の実施例である認証ポリシー生成のフローチャートを示す図である。認証ポリシーの生成には、上記のようにｃａｌｌｅｒＴｙｐｅ属性に値を設定する注釈が付けられた場合に、サービスのｃａｌｌｅｒＴｙｐｅを調べる（Ｓ２１０）。図９の例では、ｃａｌｌｅｒＴｙｐｅはｔｒａｖｅｌｅｒであるので、ｔｒａｖｅｌｅｒに関係して調べればよいことがわかる。次にサービスとデプロイ（ｄｅｐｌｏｙ）関係にあるマシン・ノードを検出する（Ｓ２２０）。デプロイ（ｄｅｐｌｏｙ）関係とは、展開関係であり、サービスはマシン・ノード（特定の機器、パソコン、ワークステーション等）に配備されるのでこのように呼ぶ。検出された結果は、図１２に示すような状態であり、マシン・ノード（Ｍ．Ｎｏｄｅ）として、顧客、旅行代理店、航空会社が検出される。各ノードには認証基盤モデルがあらかじめ準備されている。例えば、旅行代理店については、図１３に示すような構成である。図１３に示す構成は、図５に示した内容を旅行代理店について具体的な実施例としたものである。

検出されたマシン・ノードに関して記憶部に記憶されている認証基盤モデルからｉｎｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔ（トークン言明）の情報を取得する（Ｓ２３０）。ここでｉｎｂｏｕｎｄとはマシン・ノードに入るトークン言明である。図１３の例で言えば旅行代理店のマシン・ノード（サーバ等）に入るトークン言明をいう。次に検出されたマシン・ノードに関して記憶部に記憶されている認証基盤モデルからｏｕｔｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔの情報を取得する（Ｓ２３２）。ここでｏｕｔｂｏｕｎｄとはマシン・ノードから出るトークン言明である。図１３の例で言えば旅行代理店のマシン・ノードから出るトークン言明をいう。

そして、これらの共通のＭａｐｐｉｎｇを取得する（Ｓ２４０）。ここで、Ｍａｐｐｉｎｇとは、セキュリティ・ドメイン間の対応関係を定義する要素である。複数のＴｏｋｅｎＳｔａｔｅｍｅｎｔ間の対応関係を定義することにより、セキュリティ・ドメインの対応を定義する。図１３の旅行代理店の例では、顧客のＩＤ／パスワードとマイレージ番号が対応付けられる。このような対応付けをする場合にＭａｐｐｉｎｇ要素を使う。この要素では、ｓｕｂｊｅｃｔＴｙｐｅという属性を定義している。Ｍａｐｐｉｎｇ要素により、複数のＴｏｋｅｎＳｔａｔｅｍｅｎｔが対応付けられると、それらは同一のユーザ・タイプを指しているとみることができる。そこで、ｓｕｂｊｅｃｔＴｙｐｅという属性により、その名前を指定する。

次に、ＭａｐｐｉｎｇのｓｕｂｊｅｃｔＴｙｐｅを取得する（Ｓ２４２）。旅行代理店の例では、ｉｎｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔ（トークン言明）とｏｕｔｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔの共通Ｍａｐｐｉｎｇは、図１３に示すように、ｔｒａｖｅｌｅｒであるのでｔｒａｖｅｌｅｒが取得される。

取得されると、サービスのｃａｌｌｅｒＴｙｐｅとＭａｐｐｉｎｇのｓｕｂｊｅｃｔＴｙｐｅは同じか検証される（Ｓ２５０）。同じ場合は記憶部に記憶されている認証基盤モデル内容が認証ポリシーに取り入れられる（Ａ）。同じでない場合は取り入れられないので終了する（Ｂ）。

同じ場合は、ｉｎｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔの情報を認証ポリシーの内部データ構造のＴｏｋｅｎＡｓｓｅｒｔｉｏｎの部分に埋め、ｓｅｃｕｒｉｔｙＤｏｍａｉｎ属性を認証ポリシーのＳｅｃｕｒｉｔｙＤｏｍａｉｎ要素に埋める（Ｓ２６０）。

同様に、ｏｕｔｂｏｕｎｄのＴｏｋｅｎＳｔａｔｅｍｅｎｔの情報を認証ポリシーの内部データ構造のＴｏｋｅｎＡｓｓｅｒｔｉｏｎの部分に埋め、ｓｅｃｕｒｉｔｙＤｏｍａｉｎ属性を認証ポリシーのＳｅｃｕｒｉｔｙＤｏｍａｉｎ要素に埋める（Ｓ２６２）。

次に、ＳｅｎｄｅｒＴｒｕｓｔ要素が記憶部に記憶されている認証基盤モデルの内容がついているか調査される（Ｓ２７０）。ついている場合はその内容が認証ポリシーに取り入れられる。ついていない場合は終了する。

ついている場合は、ＴｒｕｓｔＭｅｔｈｏｄ要素を認証ポリシーにつけて、ＳｅｎｄｅｒＴｒｕｓｔのＭｅｔｈｏｄ属性をＴｒｕｓｔＭｅｔｈｏｄのＭｅｔｈｏｄ属性をコピーする（Ｓ２７２）。

そして、ＳｅｎｄｅｒＴｒｕｓｔが指しているＴｏｋｅｎＳｔａｔｅｍｅｎｔ要素の情報を基にして、ＳｅｃｕｒｉｔｙＤｏｍａｉｎ要素を認証ポリシーに追加する。この際、ＴｏｋｅｎＳｔａｔｅｍｅｎｔのｓｅｃｕｒｉｔｙＤｏｍａｉｎ属性の値をＳｅｃｕｒｉｔｙＤｏｍａｉｎのｄｏｍａｉｎＮａｍｅ属性にコピーする（Ｓ２７４）。

さらに、ＳｅｎｄｅｒＴｒｕｓｔが指しているＴｏｋｅｎＳｔａｔｅｍｅｎｔ要素の情報を基にして、ＴｒｕｓｔＭｅｔｈｏｄの直下にＴｏｋｅｎＡｓｓｅｒｔｉｏｎ要素を認証ポリシーに追加する（Ｓ２７６）。

以上の様にして、認証ポリシーを生成することができる。生成された認証ポリシーの例を図１４と図１５に示す。図１４は、本発明の実施例である顧客が旅行会社にアクセスする場合の生成された認証ポリシーを示す図である。ここでは、図１４の５行目のＴＡＣｕｓｔｏｍｅｒドメインのＩＤ／パスワードを使い、これで認証する（信頼は必要ない）。

また、図１５は、本発明の実施例である旅行会社からマイル番号を送って航空会社にアクセスする場合の生成された認証ポリシーを示す図である。マイル番号のみを送るので、別途信頼方法（ＴｒｕｓｔＭｅｔｈｏｄ）が必要である。この場合、旅行代理店ＩＤ（ａｇｅｎｔＩＤ）のセキュリティドメインのＩＤが必要になる。また、認証方法はＢａｓｉｃとなっているが、これはＩＤ／パスワードでの認証を意味する。一般に、ＩＤ／パスワードによる認証をＢａｓｃｉ Ａｕｔｈｅｎｔｉｃａｔｉｏｎと呼ぶ。また、ＴｒｕｓｔＭｅｔｈｏｄの直下にＳｅｃｕｒｉｔｙＤｏｍａｉｎ要素を入れることになる。

生成された認証ポリシー４００は記憶部２（４２０）に記憶される。通常はサービス開発者は見る必要がないが、状況により必要な場合は記憶部２（４２０）に記憶されている内容を後述の表示装置１０２２に表示することにより確認することができる。

図１６は、情報処理装置１００のハードウエア構成の一例を示す。情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＡＲＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、並びにキーボード及びマウス・アダプタ等１１００の入力手段１１５を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブルディスク（ＦＤ）ドライブ１０７２、ハード・ディスク１０７４、光ディスクドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。これらの記憶手段を記憶部１（２２０）、記憶部２（４２０）として使用することができる。

音声プロセッサ１０３０には、増幅回路１０３２及びスピーカ１０３４が接続される。また、グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。

ＢＩＯＳ１０６０は、情報処理装置１００の起動時にＣＰＵ１０１０が実行するブートプログラムや、情報処理装置１００のハードウエアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０７２は、フレキシブルディスク１０７１からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供する。

光ディスクドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク１０７７から光ディスクドライブ１０７６によりプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供することもできる。

情報処理装置１００に提供されるコンピュータプログラムは、フレキシブルディスク１０７１、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて利用者によって提供される。コンピュータプログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、又は通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、情報処理装置１００にインストールされ実行される。コンピュータプログラムが情報処理装置に働きかけて行わせる動作は、図１から図１５において説明した情報処理装置１００における動作と同一であるので省略する。

以上に示したコンピュータプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブルディスク１０７１、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体、を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハード・ディスクまたは光デスクライブラリー等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータプログラムを情報処理装置１００に提供しても良い。

以上の例は、情報処理装置について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。したがって、本発明において一つの実施形態として説明した情報処理装置は、ソフトウエア開発方法およびそのコンピュータプログラムによっても実現可能である。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明の考え方を示す概念図である。 本発明の情報処理装置の構成を示す図である。 本発明の実施例である認証ポリシーの形式を示す図である。 本発明の実施例である認証ポリシーの内部データ構造を示す図である。 本発明の実施例である認証基盤モデルのデータ構造を示す図である。 本発明のソフトウエア開発方法のアルゴリズムの概要を示す図である。 旅行代理店のシナリオを表す図である。 本発明の認証の実施例である。 本発明の注釈設定用のグラフィカルエディタの実施例である。 本発明の実施例である認証ポリシー生成のフローチャートを示す図である。 本発明の実施例である認証ポリシー生成のフローチャートを示す図である。 本発明の実施例であるサービスモデルと認証基盤モデルとの対応関係を示す図である。 本発明の実施例である旅行代理店のデータ構造を示す図である。 本発明の実施例である、顧客が旅行会社にアクセスする場合の生成された認証ポリシーを示す図である。 本発明の実施例である、旅行会社からマイル番号を送って航空会社にアクセスする場合の生成された認証ポリシーを示す図である。 情報処理装置のハードウエア構成を示す。

符号の説明

６０ オペレーティングシステム
１１０ サービス
１１５ 入力手段
１２０ 注釈設定用グラフィカルエディタ
２００ 認証基盤モデル
２２０ 記憶部１
３００ 認証ポリシー生成部
４００ 認証ポリシー
４２０ 記憶部２

Claims (13)

1. サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発する情報処理装置であって、
   前記サービスにおいて、サービスに関する注釈を入力する入力手段と、
   前記サービスが実行されるマシン・ノードの認証基盤モデルを記憶する記憶部と、
   前記注釈と前記認証基盤モデルより認証ポリシーを生成する認証ポリシー生成部と、
   を備える情報処理装置。
2. 前記入力手段は、前記サービスをモデル化したものをグラフィカルエディタ上で前記サービスに注釈を付する、
   請求項１に記載の情報処理装置。
3. 前記注釈は認証表明とコーラータイプ（ｃａｌｌｅｒＴｙｐｅ）である、
   請求項２に記載の情報処理装置。
4. 前記認証基盤モデルは、複数のサービス間の連携と、身分証明の伝播と、シングルサインオンと、サービス間の信頼関係とを含む、
   請求項１に記載の情報処理装置。
5. 前記認証ポリシーは、ユーザ身分証明の形式と、認証のための機構と、セキュリティ・ドメインと、信頼確認手段を指定するものとである、
   請求項１に記載の情報処理装置。
6. 前記認証ポリシー生成部は、
   前記サービスの注釈からコーラータイプを検出し、
   前記サービスとデプロイ関連にあるマシン・ノードを前記記憶部から検出し、
   検出されたマシン・ノードの認証基盤モデルからトークン言明の共通のマッピングを取得し、
   前記マッピングより呼出主体を取得し、
   前記コーラータイプと前記呼出主体が同一の場合は、前記マシン・ノードの受信側のトークン言明の情報と、セキュリティ・ドメインの属性とを受信側の認証ポリシーに設定し、送信側のトークン言明の情報と、セキュリティ・ドメインの属性とを送信側の認証ポリシーに設定し、
   前記トークン言明に送信者信頼法要素が付いている場合は前記信頼確認手段を認証ポリシーに設定する、
   請求項５に記載の情報処理装置。
7. サービス指向アーキテクチャにおいて秘密保持が要求されるサービスを開発するソフトウエア開発方法であって、
   前記サービスにおいて、サービスに関する注釈を入力する入力ステップと、
   前記サービスが実行されるマシン・ノードの記憶されている認証基盤モデルを読み出すステップと、
   前記注釈と前記認証基盤モデルより認証ポリシーを生成する認証ポリシー生成ステップと、
   を備えるソフトウエア開発方法。
8. 前記入力ステップは、前記サービスをモデル化したものをグラフィカルエディタ上で前記サービスに注釈を付する、
   請求項７に記載のソフトウエア開発方法。
9. 前記注釈は認証表明とコーラータイプ（ｃａｌｌｅｒＴｙｐｅ）である、
   請求項８に記載のソフトウエア開発方法。
10. 前記認証基盤モデルは、複数のサービス間の連携と、身分証明の伝播と、シングルサインオンと、サービス間の信頼関係とを含む、
    請求項７に記載のソフトウエア開発方法。
11. 前記認証ポリシーは、ユーザ身分証明の形式と、認証のための機構と、セキュリティ・ドメインと、信頼確認手段を指定するものとである、
    請求項７に記載のソフトウエア開発方法。
12. 前記認証ポリシー生成ステップは、
    前記サービスの注釈からコーラータイプを検出し、
    前記サービスとデプロイ関連にあるマシン・ノードを記憶部から検出し、
    検出されたマシン・ノードの認証基盤モデルからトークン言明の共通のマッピングを取得し、
    前記マッピングより呼出主体を取得し、
    前記コーラータイプと前記呼出主体が同一の場合は、前記マシン・ノードの受信側のトークン言明の情報と、セキュリティ・ドメインの属性とを受信側の認証ポリシーに設定し、送信側のトークン言明の情報と、セキュリティ・ドメインの属性とを送信側の認証ポリシーに設定し、
    前記トークン言明に送信者信頼法要素が付いている場合は前記信頼確認手段を認証ポリシーに設定する、
    請求項１１に記載のソフトウエア開発方法。
13. 請求項７から１２のいずれかに記載のソフトウエア開発方法の各ステップをコンピュータに実行させるコンピュータプログラム。

Images