JP4992335B2 - ポリシーファイルの分配方法およびコミュニティシステム - Google Patents

Description

この発明は、仮想的に結ばれたコミュニティに属する各エンティティへのポリシーファイルの分配方法およびコミュニティシステムに関する。詳しくは、この発明は、コミュニティを管理する管理者は、ポリシーファイルおよびエンティティリストをコミュニティに属する所定のエンティティであるメッセンジャノードに配り、このメッセンジャノードはエンティティリストに基づきコミュニティに属する他のエンティティにポリシーファイルを分配するようにすることによって、あるいはコミュニティに新たに参加するエンティティは、その参加をマルティキャストで他のエンティティに知らせ、このマルティキャストに対してレスポンスを返したエンティティからポリシーファイルを受け取るようにすることによって、コミュニティに属する各エンティティにポリシーファイルを簡単かつ安全に分配できるようにしたポリシーファイル分配方法等に係るものである。

従来の認証・認可技術として大きく分けて二つの形態がある。一つは、各リソース(resource)になるエンティティが自分自身の設定したポリシーファイルを持ち、そのポリシーファイルによって、認証・認可を行う。例えば、ＵＮＩＸ系のサーバがpasswdファイルやgroupファイルを持ち、ユーザの認証・認可を行うことは、このタイプに属する。

もう一つは、認証・認可のために別のサーバを立ち上げることである。今まで、種々の形態の認証・認可サービスが世の中に出てきている。たとえば、RADIUSサービスを行うこととか、最近ウェブサービスでも認証・認可の目的のサービスがある。この場合は、サーバの方で、詳細なポリシーを作成したり、管理したりして、あるクライアントのリソースのアクセスに対するアクセスコントロールを行うことが可能となる。例えば特許文献１に、ポリシーサーバの一例が記載されている。
特開２００５−４５４９号公報

上述したように各エンティティが自分自身の設定したポリシーファイルを持って認証・認可を行うものにあっては、以下のような問題がる。

（１）複数の端末が一つの仮想的なコミュニティに属するためには、同じポリシーを持つ必要がある。つまり、ＵＮＩＸ（登録商標）の場合は、同じ内容のpasswdファイルやgroupファイルを各端末が持つ必要がある。しかし、ポリシーが変わるたびに複数の端末のポリシーファイルを各端末管理者が変更するのは現実的に難しいし、時間的な問題も発生する。

（２）既存の認証・認可の仕組みでは、リソースの定義やアクセスコントロール(accesscontrol)を細かくするのが非常に難しい。例えば、ＵＮＩＸのpasswdファイルやgroupファイルで、多様なアクセスコントロールを表現するのは難しい。

また、上述したように認証・認可のために別サーバを立ち上げるものにあっては、以下のような問題がある。

（１）認証・認可の目的で別のサーバを立ち上げるのは、大きなサービスでは一般的なことだが、サーバを立ち上げるには経済的、時間的にコストが掛かる。

（２）各端末側は、あるクライアントからリクエストがくるとき、そのリクエストに対して許可の判断をするたびに、端末は認証・認可サーバとセキュアにやり取りすることが必要になる。

上述の理由で、既存の認証・認可の仕組みは、次のようなケースでは適当でない場合がある。

（ａ）低コストで、認証・認可の仕組みを実現する場合
例えば、駐車場みたいな小規模な場所で監視カメラを設置して、ユーザからそのカメラらへのアクセスに認証・認可を行う場合があるとする。アクセスは、管理者からの設定のためのアクセスと、ただカメラからの映像を見るだけのアクセスなど、アクセスのレベルが分かれている。ユーザのレベルによって、カメラへのアクセスの可能なリソースも分かれている。

（ｂ）簡単に仮想的なコミュニティを作って、そのコミュニティのエンティティ間の認証・認可の仕組みを構築する場合
例えば、友達とファイル共有のため、友達のＰＣから私のＰＣへのアクセスを許可しつつ、私のＰＣ中のどのファイルやディレクトリへのアクセスを認可するかというポリシーを設定する。その設定によって、私と友達の間のファイル共有を可能にする。

この発明の目的は、仮想的に結ばれたコミュニティに属する各エンティティにポリシーファイルを簡単かつ安全に分配可能とすることにある。

この発明の概念は、
仮想的に結ばれたコミュニティに属する各エンティティに同じポリシーファイルを分配する方法であって、
上記コミュニティを管理する管理者は、上記ポリシーファイルおよび該ポリシーファイルを配るエンティティが記載されたエンティティリストを、上記コミュニティに属する所定のエンティティであるメッセンジャノードに送り、
上記メッセンジャノードは、上記エンティティリストに基づき、上記コミュニティに属する他のエンティティに上記ポリシーファイルを分配し、
上記メッセンジャノードは、上記エンティティリストに含まれるエンティティ数が所定数より多いときは、該エンティティリストを複数のエンティティサブリストに分割し、該複数のエンティティサブリストをそれぞれ該エンティティサブリストに含まれる所定のエンティティであるサブメッセンジャノードに、上記ポリシーファイルと共に配り、
上記サブメッセンジャノードは、上記エンティティサブリストに基づき、該エンティティサブリストに含まれるエンティティに上記ポリシーファイルを配り、分配状況を上記メッセンジャノードに報告する
ポリシーファイルの分配方法にある。

この発明において、仮想的に結ばれたコミュニティには複数のエンティティが属している。このコミュニティを管理する管理者（アドミニストレータ）が作成または更新したポリシーファイルは各エンティティに分配される。その際、まず、コミュニティを管理する管理者から、所定のエンティティであるメッセンジャノードに、ポリシーファイルおよびエンティティリストが送られる。そして、このメッセンジャノードにより、エンティティリストに基づいて、他のエンティティにポリシーファイルが分配される。このようにして各エンティティにポリシーファイルを分配することで、管理者が作成または更新したポリシーファイルを簡単かつ安全に分配できる。

例えばこの場合、メッセンジャノードでは、コミュニティに属する他のエンティティに対するポリシーファイルの分配情報がアップデートされながら分配が終了するまでポリシーファイルの分配が管理される。これにより、管理者は、最初にメッセンジャノードにポリシーファイルおよびエンティティリストを送るのみで済み、また分配状況をメッセンジャノードでアップデートされている分配情報から容易に知ることができる。

また例えば、メッセンジャノードでは、エンティティリストに含まれるエンティティ数が所定数より多いときは、このエンティティリストが複数のエンティティサブリストに分割され、この複数のエンティティサブリストがそれぞれこのエンティティサブリストに含まれる所定のエンティティであるサブメッセンジャノードに、ポリシーファイルと共に配ることが行われる。そして、サブメッセンジャノードでは、エンティティサブリストに基づき、このエンティティサブリストに含まれるエンティティにポリシーファイルを配ることが行われると共に、その分配状況をメッセンジャノードに報告することが行われる。これにより、ポリシーファイルの分配を効率よく行うことが可能となる。

例えば、上述した分配時にコミュニティに入っておらず、その後にコミュニティに参加するエンティティは、その参加を、マルティキャストでコミュニティに属する他のエンティティに知らせ、このマルティキャストに対してレスポンスを返したエンティティからポリシーファイルを受け取るようにされる。これにより。コミュニティに新たに参加するエンティティに対しても簡単かつ安全にポリシーファイルを分配できる。

そしてこの場合、例えば、コミュニティに新たに参加するエンティティでは、マルティキャストに対してレスポンスを返したエンティティが複数存在するとき、到着が最も早いレスポンスを返したエンティティからポリシーファイルを受け取るようにされる。このようにレスポンスの到着が早いということはそのレスポンスを返したエンティティがネットワークのトポロジー的に近いかあるいはそのエンティティの現在の負荷が低いことを意味しており、そのエンティティからポリシーファイルを安定して、かつ素早くダウンロードすることが可能となる。

なお、このようにコミュニティに新たに参加したエンティティでは、ポリシーファイルをダウンロードして受け取った後に、そのことを上述したメッセンジャノードに知らせるようにされる。これにより、メッセンジャノードは新たにコミュニティに参加したエンティティに対するポリシーファイルの分配状況も適切に把握できる。

この発明によれば、コミュニティを管理する管理者は、ポリシーファイルおよびエンティティリストをコミュニティに属する所定のエンティティであるメッセンジャノードに配り、このメッセンジャノードはエンティティリストに基づきコミュニティに属する他のエンティティにポリシーファイルを分配するものであり、あるいはコミュニティに新たに参加するエンティティは、その参加をマルティキャストで他のエンティティに知らせ、このマルティキャストに対してレスポンスを返したエンティティからポリシーファイルを受け取るものであり、コミュニティに属する各エンティティにポリシーファイルを簡単かつ安全に分配できる。

この発明は、SeComi(Secure Community) Frameworkという仮想的なコミュニティ内の認証・認可技術の一部である。SeComi Frameworkとは仮想的に結ばれたコミュニティのエンティティ間で各エンティティにあるリソースへのアクセスのコントロールを行うために、アクセスコントロールに使われるポリシーファイルをエンティティ間で共有することによって、コミュニティの中の認証・認可仕組みを実現する技術である。このSeComi フレームワークは、以下の二つのサーブフレームワークに分かれている。

（１）ポリシー分配フレームワーク(Policy DistributionFramework)
同じ仮想コミュニティに属するエンティティに同じポリシーファイルを配る技術。配る時はポリシーを受けるエンティティが確実にそのコミュニティに属しているのかを確認（認証・認可）しながら分配を行う。

（２）ポリシーの評価による認証・認可(Policy Evaluation forAuthentication and Authorization)
コミュニティの中で配られたポリシーファイルを用いて、実際にリソースへのアクセスがくる時、認証・認可を行う。

この発明は、ポリシー分配フレームワークに関する発明である。この発明の実施の形態を以下の順序で説明する。
1.1 用語定義
1.2 ポリシー分配技術の機能要件
1.3 ポリシー分配モード
1.4 コミュニティメンバー（エンティティ）になる条件
1.5 ポリシーパッケージ（POLICY PACKAGE）
1.6 PDTOKEN
1.7 プッシュモード（Push Mode）
1.7.1 概要
1.7.2 プッシュモードのセッション生成とメッセージの種類
1.7.3 シナリオの例
1.7.4 シークエンスダイアグラム
1.8 プルモード
1.8.1 概要
1.8.2 プルモードで使われるメッセージの種類
1.8.3 シナリオの例
1.8.4 シークエンスダイアグラム
1.9 効果

1.1 用語定義

（１）コミュニティ(community)
コミュニティは、ネットワーク上で仮想的に結ばれたエンティティの集合である。コミュニティは、管理者（アドミニストレータ）が決めるコミュニティコンフィギュレーションファイルよって定義され、コミュニティのメンバーも管理者が決めるエンティティリストによって定義される。

（２）エンティティ(entity)
エンティティは、自分のクリデンシャル(credential)を持っている、ＰＫＩ(Public Key Infrastructure)概念上のエンティティを指している。クリデンシャルは、自分の個人鍵と公開鍵の証明書であって、コミュニティが認める信頼するルート認証局(Trusted Root CA)から発行したものである。

1.2 ポリシー分配技術の機能要件
ポリシーは、コミュニティを管理する管理者（アドミニストレータ）により作成され、当該管理者により配られる。管理者が新しいポリシーを配り始めた後、コミュニティのエンティティの中で、どのエンティティが新しいポリシーを受け取ったのか、どのエンティティがまだ受け取ってないのかを確実に分かる必要がある。その分配の状況によって、管理者は分配を続けるか、一旦止めて、やり直すかを決定できる。

ポリシーの分配は、基本的には、ネットワークに参加しているエンティティに対して行う。しかし、ポリシー分配中にはネットワークに参加していなくても、後でネットワークに参加したエンティティについては、持っているポリシーファイルをコミュニティが持っている最新版のポリシーファイルにすぐに更新する必要がある。

ポリシーファイルの分配は十分安全に行う必要がある。ポリシーファイルの受け側は確実に管理者が定義したコミュニティのメンバーでないといけない。ポリシーファイル自体は緊密性(confidentiality)のあるものなので、改ざんされたり、盗まれたりするといけない。

1.3 ポリシー分配モード
ポリシー分配は、図１に示すように、二つのモードで行う。

（１）プッシュモード(Push Mode)
プッシュモードは、コミュニティを定義する管理者がコミュニティポリシーを作成、または更新した後、全てのコミュニティエンティティに配るとき使うモードである。このプッシュモードでは、基本的にネットワークに参加しているエンティティに限り分配される。すなわち、分配時にネットワークに参加していないエンティティはポリシーを受け取ることができない。

（２）プルモード(Pull Mode)
コミュニティに属するエンティティが、ネットワークから離れた後、新たにネットワークに参加するとき、コミュニティの他のエンティティから最新版のポリシーファイルを受け取るとき使うモードである。

1.4 コミュニティメンバー（エンティティ）になる条件
あるエンティティが特定のコミュニティに属するには次の条件を満たす必要がある。

（１）コミュニティの管理者（アドミニストレータ）が発行したコミュニティコンフィギュレーションファイルを持つこと。

コンフィギュレーションファイルは、（ａ）コミュニティの名前やユニークに識別するためのグロバルＩＤ、（ｂ）管理者のX509 証明書のSubject DN、を含んでいる。このコンフィギュレーションファイルによって、エンティティがどのコミュニティに属していて、そのコミュニティの管理者が誰なのかを知ることができる。以下に、コンフィギュレーションファイルの一例を示す。

<communityConfig>
<community>
<communityName>SampleSecomiCommunity</communityName>
<communityUri>secomi://certain.organization.com/group1</communityUri>
</community>
<administrator>
<subjectDN>C=JP, ST=Tokyo, O=MyOrg, OU=OrgUnit,CN=Admin</subjectDN>
<issuerDN>C=JP, ST=Tokyo, O=MyOrg, OU=OrgUnit, CN=Root</issuerDN>
</administrator>
</communityConfig>

（２）エンティティは、自分のクリデンシャルを持つこと。すなわち、個人鍵と公開鍵の証明書を持つこと。証明書を発行した認証局はコミュニティが信頼する認証局であること。

（３）コミュニティに属するエンティティは、管理者が管理するエンティティリスト(EntityList)に入ること。エンティティリストには、そのコミュニティに属するエンティティのX509 証明書のSubject DNとポリシー分配に使われるアドレスとポート番号が含まれる。アドレスやポート番号は、他のエンティティがそのエンティティのポリシーを転送するとき、接続するポイントになる。以下にエンティティリストの一例を示す。

<entityList>
<entity>
<subjectDN>C=JP, ST=Tokyo, O=MyOrg, OU=OrgUnit,CN=Node-001</subjectDN>
<address port="7000">192.168.235.229</address>
</entity>
<entity>
<subjectDN>C=JP, ST=Tokyo, O=MyOrg, OU=OrgUnit, CN=Node-002</subjectDN>
<address port="7000">192.168.235.230</address>
</entity>
<entity>
<subjectDN>C=JP, ST=Tokyo, O=MyOrg, OU=OrgUnit,CN=Node-003</subjectDN>
<address port="7000">192.168.235.231</address>
</entity>
</entityList>

1.5 ポリシーパッケージ（POLICY PACKAGE）
ポリシーファイルは、通常複数のファイルにより構成される。それらのファイルを一つのパッケージにして、分配することになる。ポリシーパッケージは<PolicyPackage>という一つのXML elementによってリンクされ、コミュニティ管理者によって一緒にＸＭＬ署名される。<PolicyPackage>は、複数のポリシーファイルを一つのパッケージとしてパッケージングするだけではなく、次のような情報も含んでいる。

（１）ポリシーファイルのフォーマット
この発明ではポリシーのフォーマットは関係しない。ポリシーファイルのフォーマットはポリシー評価による認証・認可仕組みに依存する。ただし、ポリシーファイルを運ぶパッケージとして、パッケージの中のポリシーファイルがどのようなフォーマットになっているのかを記述する。

（２）ポリシーバージョン(Policy Version)
ポリシーバージョンは、ポリシーパッケージの識別のための固有ナンバーである。ポリシーバージョンは、ポリシーパッケージ間でバージョンを比較する際に使われる。

（３）シリアル番号(Serial Number)
ポリシーファイルの分配を始めるたびに新しい番号をパッケージにつける。同じポリシーパッケージを分配するときでも、新しいシリアル番号が付けられる。シリアル番号はポリシー分配を識別するための識別子である。

上述した情報の他に、<PolicyPackage>は各ポリシーファイルのレファランスポインタ(Reference Pointer)を持つ。最後には、レファランスポインタで結ばれた全てのポリシーファイルと<PolicyPackage>の内容に対して、コミュニティ管理者の個人鍵(PrivateKey)でXML Signatureを付ける。
図２は、ポリシーパッケージの一例を示している。

1.6 ＰＤＴＯＫＥＮ
ポリシーパッケージの分配は、まずコミュニティ管理者がPDTokenを発行して、それをメッセンジャノードに送ることから始まる。PDTokenには、まず誰がポリシーパッケージの分配を開始したのか、すなわち、誰がコミュニティの管理者なのかを記述する。そして、どのエンティティがポリシーパッケージ分配の責任を持つか、すなわち、どのエンティティがメッセンジャノードになるかを記述する。そして、ポリシーパッケージのバージョン番号、シリアル番号、タイムスタンプ(Timestamp)など、ポリシーパッケージの分配に必要となる情報を入れ、それに管理者の個人鍵でＸＭＬ署名を付ける。

すなわち、PDTokenには、（ａ）コミュニティの名前と識別子、（ｂ）ポリシーバージョン、（ｃ）メッセンジャノードの情報、（ｄ）シリアル番号、（ｅ）タイムスタンプ、（ｆ）上述の内容に対する管理者によるXML Signature、（ｇ）XML Signatureの検証のための管理者のX509 証明書、が含まれる。以下にPDTokenの一例を示す。

<pdToken>
<community>
<communityName>SampleSecomiCommunity</communityName>
<communityUri>secomi://certain.organization.com/group1</communityUri>
</community>
<policyVersion>1.0.0</policyVersion>
<messenger>
<subjectDN>C=JP, ST=Tokyo, L=Tokyo, O=Org, OU=OrgUnit,CN=Node-001</subjectDN>
<address port="7001">192.168.0.229</address>
</messenger>
<serialNumber>1</serialNumber>
<timestamp>2006-02-10 Fri 13:19:19</timestamp>
<adminEmail>community-admin@mycommunity.com</adminEmail>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethodAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference>
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>im1HhEY5shsBz/3U5uG4nLKVR1M=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>hhB6fHkHxOwA0LKN+bZ0ApiBEw3LUIOi/rEeEtM3Hz3DV8Q/AA/3g/ES3eN62IR3
rZ1QLLpnehZdk87rHcxMVOg2dS2AI5xwJrI+l2KxWyjzEbRPMuSWoeZtUxFvUZ31
ZmDgdppIFZz7sOPoTt47JaSI6esSwWpuUJi0+FLUwsA=</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDDDCCAnWgAwIBAgIBCzANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGwJKUDEO
MAwGA1UECBMFVG9reW8xDjAMBgNVBAcTBVRva3lvMQ0wCwYDVQQKEwRTb255MQ0w
CwYDVQQLEwRQU05DMRAwDgYDVQQDEwdSb290IENBMB4XDTA2MDIxMDA5MDEwOFoX
DTA3MDIxMDA5MDEwOFowSzELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMQ0w
CwYDVQQKEwRTb255MQ0wCwYDVQQLEwRQU05DMQ4wDAYDVQQDEwVBZG1pbjCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3FdPPqmGrQ1fH9mMpcSBKKIDL9QFVugT
MagQurpK14o1FSjaYj8I5XSebG5zc5n2J1U7bCiW2zY7rAQwmn+rbNe13FeC31WJ
sOS1WeEYAKwfSCREiZso6soGnD9Jcdl/TJIZejXR6H4F1RgJ1fDWI60+1txMIJUl
YJTfXSqsQsUCAwEAAaOB7TCB6jAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1P
cGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUB6YfFimxisW8
ZyK11O0cbxED3+UwgY8GA1UdIwSBhzCBhIAUn0ZEnzcuWK5OJbpDeLeQ9RqdqReh
YaRfMF0xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEOMAwGA1UEBxMFVG9r
eW8xDTALBgNVBAoTBFNvbnkxDTALBgNVBAsTBFBTTkMxEDAOBgNVBAMTB1Jvb3Qg
Q0GCCQC9hj2HfaAi/zANBgkqhkiG9w0BAQUFAAOBgQBN77uhYNwgF2vbjOEvviJm
OI3tk8zPp/C6SxUUd9m9W3OlhbDph0uepeC2eZTHn+n71VptHytw1rKMf76wUUM9
G6BGa3R8tbyyCUDYaiq/7YcGHinfsFARx8Z+sjCmGt+QGGjFDtubEW1TuCXOek9I
VreyhUJymKQYWlyVwxVkvw==</X509Certificate>
</pdToken>
</X509Data>
</KeyInfo>
</Signature>
</pdToken>

全てのポリシーパッケージの転送は、最初にPDTokenを送ることから始まる。PDTokenの受け側は、まずPDTokenが正しいか否を確認する。この確認は、まずXML署名に対したXML 署名検証を行い、その後は次の確認を行う。

（１）PDTokenに記述されているコミュニティが、受け側のエンティティが属しているコミュニティ、すなわち、コミュニティコンフィギュレーションファイルに定義されているコミュニティの情報と同一なのかを確認する。

（２）PDTokenに記述されている管理者(Administrator)の情報が、受け側のコミュニティコンフィギュレーションファイルに定義されている管理者の情報と同一なのかを確認する。

（３）PDTokenに記述されているポリシーのバージョンが、受け側が持っているポリシーパッケージのバージョンより新しいバージョンなのかを確認する。もし、PDTokenのポリシーバージョンが同じ、もしくは、古い場合は、受け側のエンティティとしては、そのポリシーパッケージを受ける必要がなくなる。

1.7 プッシュモード（PushMode）
1.7.1 概要
ポリシーパッケージが更新された時、コミュニティ管理者によって、新しいポリシーパッケージの分配が開始される。このポリシーパッケージの分配はセッションベースで行われる。セッションはPDTOKENメッセージによってオープン(open)され、CONTROL ENDメッセージによってクローズ(close)される。

まず、図３のように、管理者はポリシーパッケージとエンティティリストをメッセンジャノード(Messenger Node)に配る。メッセンジャノードは、コミュニティに属する複数のエンティティの中から管理者によって選ばれる。メッセンジャノードは、ポリシーパッケージの分配の状態、すなわち、どのエンティティがポリシーパッケージを受けたのか、などの情報をアップデートしながら、分配が終わるまで、分配を管理する。

メッセンジャノードは、エンティティリストのサイズによって、他のエンティティに直接ポリシーパッケージを送るか、あるいはエンティティリストに含まれるエンティティ数が所定数より多い場合は、エンティティリストを適当に分けて、各エンティティリストのサブセット（エンティティサブリスト）をサブメッセンジャノード(Sub-Messenger node)に配る。エンティティリストのサブセットを受けたサブメッセンジャノードは、そのサブセットの中のエンティティに直接ポリシーパッケージを配る。

プッシュモードで、コミュニティ管理者、メッセンジャノード、サブメッセンジャノードが果たす役割をまとめると、以下のようになる。

（１）コミュニティ管理者
（ａ）ポリシーパッケージの分配を開始する。（ｂ）ポリシーファイルを分配する前に、コミュニティに属するエンティティの中から一つのエンティティを選び、そのエンティティをメッセンジャノードにする。（ｃ）PDTokenを発行する。PDTokenにはメッセンジャノードの情報など、ポリシーパッケージの分配に必要となる情報を含める（1.6 ＰＤＴＯＫＥＮの項参照）。

（２）メッセンジャノード(Messenger Node)
（ａ）コミュニティの中で、ポリシーパッケージの分配を管理する。（ｂ）管理者からもらったポリシーパッケージを、エンティティリストに定義されている各エンティティに配る。（ｃ）もし、エンティティの数が多い場合は、そのリストを少ない数のサブリストに分け、各サブリストに対して分配を行う。

サブリストに対した分配は、管理者が最初にメッセンジャノードを決めることと同じように、まず、サブリストから一つのエンティティを選んで、そのエンティティにポリシーパッケージとエンティティサブリスト(Entity Sub-List)を送る。その後のサブメッセンジャ内の動作はメッセンジャノードと一緒である。

（ｄ）現時点でのポリシーパッケージの分配ステータスを維持しながら、管理者からの照会がある場合、現時点での分配ステータスを管理者に知らせる。つまり、メッセンジャノードは、ポリシーパッケージが配られたエンティティと、まだポリシーパッケージが配られていないエンティティのリストを管理する。

（３）サブメッセンジャノード(Sub Messenger Node)
（ａ）メッセンジャノードの代わりにポリシーパッケージをエンティティサブリストに定義されている各ノードに配る。（ｂ）一回分配した後、分配のステータスをメッセンジャノードに報告する。このサブメッセンジャノードは、メッセンジャノードとは違い、分配が終わるまで分配を管理することではなく、一回分配した後、その結果をメッセンジャノードに報告するだけである。報告した後はサブメッセンジャノードとしての機能は終わる。

1.7.2 プッシュモードのセッション生成とメッセージの種類
プッシュモードは、まず、最初に送り側のエンティティから受け側のエンティティへのＴＬＳ(TransportLayer Security)セッションを張ることから始まる。ポリシーパッケージの分配のとき、送り側は受け側のＸ５０９証明書のSubject DNを知っている。だから、その受け側のSubject DN情報を用いて、受け側のＴＬＳサーバ認証することができる。したがって、プッシュモードで使われるＴＬＳセッションは全てがサーバ認証を行う。さらに、後述するように、ＰＤＴＯＫＥＮメッセージの種類によって、コンテキストベース(Context-based)で、クライアント認証を行うことも可能になる。

プッシュモードで使われるメッセージには、ＰＤＴＯＫＥＮメッセージ、ＤＡＴＡメッセージ、ＣＯＮＴＲＯＬメッセージがある。以下、これらのメッセージについて説明する。

1.7.2.1 ＰＤＴＯＫＥＮメッセージ
ＰＤＴＯＫＥＮメッセージは、プッシュモードでポリシーパッケージを配るために、最初に他のエンティティとセッションを張るために使われるメッセージである。このメッセージは、ＴＬＳセッションが張られた後、すぐ送られる。このメッセージには、PDTokenの情報が含まれている。受け側はPDTokenを受け取って、上述したように、PDTokenの内容を確認した後、そのPDTokenセッションを続けるかどうかを判断する。

このＰＤＴＯＫＥＮメッセージには、そのメッセージの目的が記述されており、その目的によって伴うデータの種類が異なる。このメッセージのタイプとしては、「ＩＮＩＴ」、「ＤＩＳＴ」、「ＵＰＬＯＡＤ」、「ＲＥＰＯＲＴ」、「ＱＵＥＲＹ」などがある。

（１）「ＩＮＩＴ」
ＩＮＩＴメッセージはコミュニティ管理者が最初にポリシーパッケージの分配を開始する時、メッセンジャノードに送るＰＤＴＯＫＥＮメッセージである。だから、送り側は必ずコミュニティ管理者であり、受け側を管理者が決めて、PDTokenデータにも書かれているメッセンジャノードでなければならない。このＩＮＩＴメッセージによって、新しいポリシーパッケージの分配が始まる。ＩＮＩＴメッセージを受け取ったエンティティ、すなわち、メッセンジャノードは、一緒に受け取ったエンティティリストのサイズ（エンティティ数）を見て、次にＤＩＳＴメッセージ、またはＵＰＬＯＡＤメッセージを他のエンティティに送る。

（２）「ＤＩＳＴ」
ＤＩＳＴメッセージは、メッセンジャノードがＰＤＴＯＫＥＮ ＩＮＩＴメッセージを受け取った後、管理者からもらったエンティティリストのサイズが所定サイズより大きい場合、エンティティリストを適当に分けてサブリストにし、各サブリストの一つのエンティティにポリシーパッケージとエンティティサブリストを配るためのＰＤＴＯＫＥＮメッセージである。ＤＩＳＴメッセージを受け取るエンティティはサブメッセンジャノードになる。

（３）「ＵＰＬＯＡＤ」
ＵＰＬＯＡＤメッセージは、メッセンジャノード、またはサブメッセンジャノードが、受け取ったポリシーパッケージを、一緒に受け取ったエンティティリストに含まれる各エンティティに配るためのＰＤＴＯＫＥＮメッセージである。ＵＰＬＯＡＤメッセージが成功すると、すなわち、このメッセージによって、ポリシーパッケージが受け側のエンティティに成功的に渡されると、ＵＰＬＯＡＤメッセージの送り側は、受け側が確かにポリシーパッケージを受け取ったと判断することができる。もし、エラーが出たときとか、ネットワークの問題でＵＰＬＯＡＤメッセージを送ることができない場合には、受け側がポリシーパッケージを受け取れなかったと判断できる。サブメッセンジャノードは、その結果を後で、ＲＥＰＯＲＴメッセージによってメッセンジャノードに知らせる。

（４）「ＲＥＰＯＲＴ」
ＲＥＰＯＲＴメッセージは、サブメッセンジャノードが、メッセンジャノードからもらったエンティティリストの中の各エンティティにＵＰＬＯＡＤメッセージでポリシーパッケージを送った後に、その結果をメッセンジャノードに報告するためのＰＤＴＯＫＥＮメッセージである。ここで、結果は、分配結果リスト(Distribution Result List)という形式で、エンティティ毎にそのエンティティの情報と分配結果を記述して、ＲＥＰＯＲＴメッセージのセッションで一緒に送る。

（５）「ＱＵＥＲＹ」
ＱＵＥＲＹメッセージは、管理者が現在進行中のポリシー分配の状態を調べるためのＰＤＴＯＫＥＮメッセージである。ＱＵＥＲＹメッセージはコミュニティ管理者しか送れないし、メッセンジャノードにしか送れない。ＱＵＥＲＹメッセージを受け取ったメッセンジャノードは現在の分配の状態を分配結果リストの形式で管理者に返す。

1.7.2.2 ＤＡＴＡメッセージ
ＰＤＴＯＫＥＮメッセージによってセッションができると、次にＤＡＴＡメッセージによって実際に送ろうとしているデータを送る。データの種類によって、次のメッセージタイプに分かれる。

（１）「ENTITYLIST」
ENTITYLISTは、ポリシーパッケージが配られるエンティティのリストである。ＰＤＴＯＫＥＮのＩＮＩＴメッセージやＤＩＳＴメッセージでは、このENTITYLISTデータが一緒に送られる。

（２）「POLICYPACKAGE」
POLICYPACKAGEは、ポリシーパッケージである。ＰＤＴＯＫＥＮのＩＮＩＴメッセージ、ＤＩＳＴメッセージ、さらにはＵＰＬＯＡＤメッセージでは、このPOLICYPACKAGEデータが一緒に送られる。

（３）「DISTRIBUTIONRESULT」
DISTRIBUTIONRESULTは、ポリシーパッケージの分配結果である。エンティティ毎に、エンティティ情報と分配結果が記述されている。ＲＥＰＯＲＴメッセージ、ＱＵＥＲＹメッセージでは、このDISTRIBUTIONRESULTデータが一緒に送られる。

1.7.2.3 ＣＯＮＴＲＯＬメッセージ
ＣＯＮＴＲＯＬメッセージは、ＰＤＴＯＫＥＮメッセージによって作られたセッションを閉めるためのメッセージである。全てのデータが受け側に送られた後とか、セッション中に、進行中の処理をキャンセルするときに使う。注意することは、ＰＤＴＯＫＥＮメッセージやＤＡＴＡメッセージの処理の途中でも、エラーが発生したときは、その場でセッションが終わることになる。エラーが発生した時や、途中でキャンセルされた時は、受け側は今まで受けたデータは全部捨てることになる。このＣＯＮＴＲＯＬメッセージには、次のように二つのタイプがある。

（１）「ＥＮＤ」
ＥＮＤメッセージは、進行中のセッションを成功的に終了するためのＣＯＮＴＲＯＬメッセージである。ＰＤＴＯＫＥＮメッセージの受け側は、このＥＮＤメッセージによって、今まで受け取ったデータの処理を反映し始める。

（２）「ＣＡＮＣＥＬ」
ＣＡＮＣＥＬメッセージは、進行中のセッションをキャンセルするためのＣＯＮＴＲＯＬメッセージである。ＰＤＴＯＫＥＮメッセージの受け側はこのＣＡＮＣＥＬメッセージによって、今まで受け取ったデータを全部捨てて、元の状態に戻る。

1.7.3 シナリオの例
このシナリオの例では、コミュニティ管理者が、コミュニティのメンバーになるエンティティＡからエンティティＯまで、ポリシーパッケージを分配することを説明する。

まず、図４に示すように、最初に管理者（アドミニストレータ）はメッセンジャノードをエンティティＡに決め、このエンティティＡにＩＮＩＴメッセージを送る。ＩＮＩＴメッセージをもらったエンティティＡはメッセンジャノードになる。

次に、図５に示すように、メッセンジャノードＡは、管理者からもらったエンティティリストを見て、これからの分配に対して、ＵＰＬＯＡＤメッセージで各エンティティに直接ポリシーパッケージを送るか、または、サイズが大きい（エンティティ数が多い）のでリストを分けて、各サブリストに対して、サブメッセンジャノードを決め、ＤＩＳＴメッセージを送るかを決める。この例ではリストを分けて、ＤＩＳＴメッセージで送ることにする。

次に、図６に示すように、各サブメッセンジャノードＢ，Ｇ，Ｌは受け取ったサブリストの各エンティティにポリシーパッケージを配る。この例では、その結果、サブメッセンジャノードＢにおいては、エンティティＥ，Ｆに送ることが失敗し、サブメッセンジャノードＧにおいては、エンティティＨに送ることが失敗し、サブメッセンジャノードＬにおいてはエンティティＮに送ることが失敗している。

次に、図７に示すように、各サブメッセンジャノードＢ，Ｇ，Ｌは自分が実行したＵＰＬＯＡＤの結果をＲＥＰＯＲＴメッセージでメッセンジャノードＡに知らせる。ＲＥＰＯＲＴメッセージを受け取ったメッセンジャノードＡは自分が管理している分配状態データを更新する。

次に、図８に示すように、メッセンジャノードＡの最初のＤＩＳＴメッセージが終わった後、ポリシーパッケージがエンティティリストの全てのエンティティに配られなかった場合、ある程度の時間が経った後、メッセンジャノードＡは分配が失敗した残りのエンティティに対して、もう一回分配を始める。この場合、残りのエンティティＥ，Ｆ，Ｈ，Ｎの中でエンティティＥをサブメッセンジャノードにして、ＤＩＳＴメッセージを送る。

次に、図９に示すように、エンティティＥは、リストのエンティティＦ，Ｈ，Ｎに対して、ＵＰＬＯＡＤメッセージを送る。この例では、その結果、エンティティＦ，Ｎは成功し、エンティティＨはまた失敗している。

次に、図１０に示すように、サブメッセンジャＥは、その結果をメッセンジャノードＡにＲＥＰＯＲＴメッセージで知らせる。メッセンジャノードＡはそれによって、自分が管理する分配状態データを更新する。

以上のシナリオの中で、管理者はＩＮＩＴメッセージを出した後、いつでもＱＵＥＲＹメッセージで、メッセンジャノードＡに現在の分配状態を照会することができる。

1.7.4 シークエンスダイアグラム
1.7.4.1 管理者とメッセンジャノード間のやり取り

図１１は、管理者とメッセンジャノード間のやり取りを示す。管理者とメッセンジャノード間のやり取りは、ＰＤＴＯＫＥＮメッセージであるＩＮＩＴメッセージおよびＱＵＥＲＹメッセージが該当する。これらのメッセージは送り側が管理者でなければならないので、メッセンジャノードは送り側が管理者なのかを、ＴＬＳセッションが張られた後、確認する。この認証は、ＴＬＳセッション生成時に行うピーア(peer)認証ではなくて、ＴＬＳセッションが張られたあとの認証なので、本記述ではこの認証をコンテキストベース(Context-based)の認証と言う。

管理者に対するコンテキストベース認証は、メッセンジャノードがＩＮＩＴメッセージまたはＱＵＥＲＹメッセージを受けた時、送り側が管理者なのかを確認する。もし、送り側がメッセンジャノードの持っているコミュニティコンフィギュレーションファイルにある管理者の情報とマッチしないときは、エラーを返した後、ＰＤＴＯＫＥＮメッセージ（ＩＮＩＴメッセージまたはＱＵＥＲＹメッセージ）によって作られたセッションを切る。

ＩＮＩＴメッセージが成功的にメッセンジャノードによって受け取られた後は、管理者は、エンティティリストおよびポリシーパッケージを、それぞれ、ＤＡＴＡメッセージであるENTITYLISTメッセージおよびPOLICYPACKAGEメッセージを使って、メッセンジャノードに送る。管理者は、エラーが出ない場合、最後にCONTROL ENDメッセージをメッセンジャノードに送って、セッションを終了する。

また、ＱＵＥＲＹメッセージが成功的にメッセンジャノードに受け取られた後は、メッセンジャノードは、現在の分配状態の報告データを、ＤＡＴＡメッセージのDISTRIBUTIONRESULTメッセージを使って、管理者に送る。そして、最後に、管理者は、CONTROL ENDメッセージをメッセンジャノードに送って、セッションを終了する。

1.7.4.2 メッセンジャノードとサブメッセンジャノード間、およびサブメッセンジャノードと普通のエンティティ間のやり取り

図１２は、メッセンジャノードとサブメッセンジャノード間、およびサブメッセンジャと普通のエンティティ間のやり取りを示す。

まず、メッセンジャノードは、管理者からもらったエンティティリストの一部をサブリストとして分けて、その分を分配するために、そのサブリストにあるエンティティを一つ選んでそのサブリストを担当するサブメッセンジャノードにする。その後、そのサブメッセンジャノードにＤＩＳＴメッセージを送る。

最初のＴＬＳセッション生成時には、他のＰＤＴＯＫＥＮメッセージを送るときと同じように、サーバ認証を行う。ＤＩＳＴメッセージは送り側がメッセンジャノードでなければならないので、サブメッセンジャノードは送り側がメッセンジャノードなのかを、ＴＬＳセッションが張られた後、確認する。サブメッセンジャノードは、ＤＩＳＴメッセージを受け取った時、一緒に送られたPDTokenデータの中にメッセンジャノードの情報が記述されているので、その情報と送り側の証明書を比較して認証を行う。

ＤＩＳＴメッセージが成功的にサブメッセンジャノードによって受け取られた後は、メッセンジャノードは、エンティティリストおよびポリシーパッケージを、それぞれ、ＤＡＴＡメッセージであるENTITYLISTメッセージおよびPOLICYPACKAGEメッセージを使って、サブメッセンジャノードに送る。メッセンジャノードは、エラーが出ない場合、最後にCONTROL ENDメッセージをメッセンジャノードに送って、セッションを終了する。

サブメッセンジャノードは、受け取ったエンティティリストに記述されている各エンティティに対してＵＰＬＯＡＤメッセージを送る。最初のＴＬＳセッション生成時には、他のＰＤＴＯＫＥＮメッセージを送るときと同じように、サーバ認証を行う。しかしこの場合、コンテキストベースのクライアント認証は行わない。

ＵＰＬＯＡＤメッセージが成功的にエンティティノードによって受け取られた後は、サブメッセンジャノードは、ポリシーパッケージを、ＤＡＴＡメッセージであるPOLICYPACKAGEメッセージを使って、エンティティノードに送る。サブメッセンジャノードは、エラーが出ない場合、最後にCONTROL ENDメッセージをエンティティノードに送って、セッションを終了する。

サブメッセンジャノードは、エンティティリストの各エンティティへＵＰＬＯＡＤメッセージを送ったあと、その結果をまとめて、メッセンジャノードにＲＥＰＯＲＴメッセージを送る。最初のＴＬＳセッション生成時には、他のＰＤＴＯＫＥＮメッセージを送るときと同じように、サーバ認証を行う。その後、受け側がメッセンジャノードなのかをコンテキストベースで認証を行う。

認証に成功すると、サブメッセンジャノードは、自分が行ったＵＰＬＯＡＤメッセージの結果をDistributionResult分配結果リスト(List)のフォーマットでまとめて、ＤＡＴＡメッセージであるDISTRIBUTIONRESULTメッセージを使って、メッセンジャノードに送る。サブメッセンジャノードは、エラーが出ない場合、最後にCONTROL ENDメッセージをメッセンジャノードに送って、セッションを終了する。メッセンジャノードは、分配結果リストを受け取って、自分が管理している分配状態データを更新する。

1.8 プルモード
1.8.1 概要
プルモード(Pull Mode)は、プッシュモード(Push Mode)でポリシーパッケージの分配を行う時点で、ネットワークに参加しておらず、ポリシーパッケージを受け取ることができなかったエンティティが、新たにネットワークに参加する時点で、最新版のポリシーパッケージを隣のエンティティからダウンロードするときに使うモードである。

プルモードは、次の２段階で行う。まず、参加エンティティは、自分が新しくコミュニティのネットワークに参加しようとすることを、マルティキャスト(multicast)で他のエンティティに知らせる。そのマルティキャストパケットを受け取ったエンティティは、参加エンティティに、PDTokenデータを含んだレスポンスをＵＤＰで直接返す。

また、そのレスポンスをもらった参加エンティティは、そのレスポンスを返したエンティティに直接ＰＤＴＯＫＥＮメッセージで接続して、そのエンティティからポリシーパッケージを受け取る。成功的にポリシーパッケージを受け取ったあと、その参加エンティティは、PDTokenデータに記述されているメッセンジャノードに直接ＰＤＴＯＫＥＮメッセージで、自分が今分配中のポリシーパッケージを受け取ったことを知らせる。メッセンジャノードはそのＰＤＴＯＫＥＮメッセージを受け取った後、自分が管理する分配状態データを更新する。

1.8.2 プルモードで使われるメッセージの種類
1.8.2.1 プルモードで動くための条件
隣のエンティティを探すためにはマルティキャストパケットを使う。この場合、同じサブネット（サブネットとはこのマルティキャストパケットが届く範囲にあるエンティティで構成される）内のエンティティしかそのパケットを受け取ることができない。コミュニティに属するエンティティは、マルティキャストパケットを受けるために、あらかじめ決められたマルティキャストアドレスとポートにリッスン(listen)していることが必要である。

1.8.2.2 隣のエンティティを探すためのメッセージ
既に最新版のポリシーパッケージを持っている隣のエンティティを探すためのメッセージには、以下に詳述する、PDRequestメッセージと、そのレスポンスになるPDResponseメッセージとがある。

（１）PDRequestメッセージ
このPDRequestメッセージは、コミュニティのエンティティの全てがオープンしている、マルティキャストアドレスやポートに、（ａ）コミュニティ情報、（ｂ）X509 証明書のSubject DN、（ｃ）送り出し側のUDPアドレスとポート番号、等のデータを含むパケットを送る。

（ａ）コミュニティ情報は、コミュニティの名前とユニークなＩＤとからなる。このコミュニティ情報によって、送り出すエンティティがどのコミュニティのポリシーパッケージを受け取りたいのかが分かる。（ｂ）X509 証明書のSubject DNは、PDRequestを送り出したエンティティがコミュニティに属しているエンティティなのかを確認するために使われる。（ｃ）送り出し側のUDPアドレスとポート番号は、PDRequestメッセージに対するレスポンスを受けるために必要となる。以下に、PDRequestメッセージの一例を示す。

<pdRequest>
<community>
<communityName>SampleSecomiCommunity</communityName>
<communityUri>secomi://certain.organization.com/group1</communityUri>
</community>
<subjectDN>C=JP,ST=Tokyo,O=Org,OU=OrgUnit,CN=Node-003</subjectDN>
<returnAddress port=”8100”>192.168.0.229</returnAddress>
</pdRequest>

（２）PDResponseメッセージ
あるエンティティがPDRequestメッセージをマルティキャストポートに送ると、そのメッセージを受け取ったエンティティは、まずそのメッセージが、自分が属しているコミュニティに対するメッセージなのか、さらにはそのメッセージを送り出したエンティティがそのコミュニティに属しているエンティティなのかを確認する。メッセージの確認が成功的に終わると、そのメッセージを受け取ったエンティティは、PDRequestメッセージに記述されているreturn addressにPDResponseメッセージをUDPパケットで返す。

PDResponseメッセージは、送り側のアドレスとポリシーパッケージ分配のためのポート番号を含んでいる。PDRequestを送ったエンティティはこのアドレスとポート番号にＴＬＳで接続して、ＰＤＴＯＫＥＮメッセージの形で相互認証を行った後、PDResponseを送ったエンティティからポリシーパッケージをダウンロードする。

また、PDResponseメッセージは、送り側のX509 証明書のSubject DNを含んでいる。この情報は後で行うＴＬＳのサーバ認証に使われる。さらに、PDResponseメッセージは、PDTokenデータを含んでいる。このデータは、PDRequestを送ったエンティティにＰＤＴＯＫＥＮメッセージを送るときに使われる。すなわち、このPDTokenデータがＰＤＴＯＫＥＮメッセージに含まれるデータになる。以下に、PDResponseメッセージの一例を示す。

PDRESPONSE 192.168.0.229 7001 SPDP/1.0
/C=JP/ST=Tokyo/O=Org/OU=OrgUnit/CN=Node-001
<?xml version”1.0”?>
<pdToken>
… …
</pdToken>

PDRequestメッセージは、マルティキャストパケットなので、そのパケットを受けるエンティティはそのメッセージを送るエンティティと同じサブネットにある全てのエンティティになる。そのため、PDResponseメッセージを送るエンティティも複数あることになる。PDResponseメッセージの受け側、すなわち、PDRequestを送ったエンティティは、自分に到着する複数のPDResponseメッセージの中で一つを取って次の処理を続けることになる。PDResponseメッセージを選択する時は次の事項を考慮することが必要となる。

（１）PDRequestメッセージの送り側エンティティが、既に、ポリシーパッケージを持っている場合、返ってくるPDResponseメッセージに含まれているPDTokenデータのポリシーバージョンが自分の持っているポリシーパッケージのバージョンより新しいバージョンであること。

この場合、PDTokenのバージョンが自分のより古いかまたは同じである場合、自分が持っているポリシーパッケージが最新版なので、PDResponseメッセージを送ってくれたエンティティからポリシーパッケージをダウンロードする必要はない。また、受けた全てのPDResponseのポリシーバージョンが古いかまたは同じである場合、自分の持っているポリシーパッケージが最新版ということで判断し、次のポリシーパッケージのダウンロードは実行しない。

（２）受けたPDResponseメッセージで自分の持っているポリシーパッケージより新しいバージョンのメッセージが複数ある場合、メッセージの到着順を考慮してダウンロードするエンティティを決める。到着が早いというのは、自分のエンティティからネットワークのトポロジー的に近いか、または、そのエンティティにおける現在の負荷が低いことを意味しており、ポリシーパッケージを比較的安定してダウンロード可能なためである。

1.8.2.3 ポリシーパッケージをダウンロードするためのPDTOKENメッセージ
PDResponseメッセージを受けた後、そのメッセージに記述されているエンティティへポリシーパッケージをダウンロードするために接続する。ポリシーパッケージのダウンロードはプッシュモードで使われたＰＤＴＯＫＥＮメッセージの形のセッションベースで行うことになる。ダウンロードのために使われるＰＤＴＯＫＥＮメッセージには、「ＲＥＱＵＥＳＴ」がある。

（１）「ＲＥＱＵＥＳＴ」
ＲＥＱＵＥＳＴメッセージは、PDResponseメッセージを送ってくれたエンティティに接続してポリシーパッケージを送ってもらうためのＰＤＴＯＫＥＮメッセージである。このメッセージの受け側、すなわち、PDResponseメッセージを送ったエンティティが、接続してくるエンティティに対して、そのエンティティがコミュニティに属しているのかをクライアント認証する。コミュニティに属していないエンティティにはポリシーパッケージを与えないためである。

1.8.2.4 ダウンロード終了後、メッセンジャノードへの通知
ＲＥＱＵＥＳＴメッセージでポリシーパッケージをダウンロードした直後、エンティティは自分のポリシーパッケージのアップデートが終了されたことをメッセンジャノードにPDTOKEN ENDNODEREPORTメッセージで通知する。進行中のポリシーパッケージの分配を担当するメッセンジャノードの情報は、PDResponseメッセージで受け取ったPDTokenデータの中に記述されている。

PDTOKEN ENDNODEREPORTメッセージを受けたメッセンジャノードは、まず、送り側のエンティティがコミュニティに属しているエンティティなのかを確認する（コンテキストベースクライアント認証）。その後、自分が管理しているポリシー分配状態データにおける送り側のエンティティの情報を更新する。

1.8.3 シナリオの例
このシナリオの例では、新しくコミュニティネットワークに参加したエンティティＨがプルモードで最新版のポリシーパッケージを受け取ることを説明する。このシナリオは、上述したプッシュモードのシナリオの続きである。

まず、図１３に示すように、新しくコミュニティネットワークに参加したエンティティＨは、PDRequestメッセージをマルティキャストで送る。その結果、エンティティＨと同じサブネットにある全てのエンティティ（エンティティＢ，Ｅ，Ｆ，Ｇ，Ｉ，Ｊ）はそのPDRequestメッセージを受け取る。

次に、図１４に示すように、PDRequestメッセージを受け取ったエンティティは、まず、PDRequestメッセージの送り側のエンティティが同じコミュニティに属しているエンティティなのかを確認する。確認後、自分の持っているPDTokenデータをPDResponseメッセージに含ませ、PDRequestメッセージに記述されているＵＤＰアドレスのポートにそのPDResponseメッセージを返す。

次に、図１５に示すように、PDResponseメッセージを返してもらったエンティティＨは、最初、受け取ったPDResponseメッセージに含まれているPDTokenデータのコミュニティが自分の属しているコミュニティなのかを確認した後、PDTokenデータに記述されているポリシーのバージョンが自分の持っているポリシーパッケージのバージョンより新しいバージョンなのかを調べる。調べた後、自分のバージョンより新しい場合は、PDResponseメッセージを送ったエンティティにＲＥＱＵＥＳＴメッセージで接続して、そのエンティティからポリシーパッケージをダウンロードする。

次に、図１６に示すように、ポリシーパッケージのダウンロードが成功的に終わった後、エンティティＨは、PDTokenデータに記述されているメッセンジャノードＡにPDTOKENENDNODEREPORTメッセージを送って自分のポリシーアップデートが終わったことを通知する。

1.8.4 シークエンスダイアグラム
図１７は、プルモードで新しいポリシーパッケージをダウンロードし、その後、メッセンジャノードに通知することを示す。この図において、新しくコミュニティネットワークに参加したエンティティＤと、エンティティＢ, Ｃは同じサブネットにある。

まず、エンティティＤは、PDRequestメッセージをマルティキャストパケットでブロードキャストする。その結果、同じサブネットにあるエンティティＢ，ＣがPDRequestメッセージを受け取る。エンティティＢ，Ｃは自分の持っているPDTokenデータを含んだPDResponseメッセージをエンティティＤに返す。

エンティティＤは返してもらったPDResponseメッセージの中で、自分の持っているポリシーバージョンより新しいバージョンのPDResponseメッセージを選択する。選択されたPDResponseメッセージが複数ある場合は、一番早く届いたPDResponseメッセージを最終的に選ぶ。そして、エンティティＤは、選んだPDResponseメッセージに記述されているアドレスにＲＥＱＵＥＳＴメッセージを送って、そのエンティティ（図示の例ではエンティティＣ）からポリシーパッケージを受け取る。

受け取った直後、エンティティＤは、PDTokenに記述されているメッセンジャノードにPDTOKEN ENDNODEREPORTメッセージを送って、自分のポリシーアップデートが終了したことを報告する。このPDTOKEN ENDNODEREPORTメッセージを受け取ったメッセンジャノードは自分の管理しているポリシー分配状態データを更新する。

1.9 効果
上述した実施の形態においては、コミュニティを管理する管理者から、所定のエンティティであるメッセンジャノードに、ポリシーファイル（ポリシーパッケージ）およびエンティティリストが送られ、その後にこのメッセンジャノードによりエンティティリストに基づいて他のエンティティにポリシーファイルが分配され（プッシュモード）、またこの分配時にコミュニティに入っておらず、その後にコミュニティに参加するエンティティは、その参加を、マルティキャストでコミュニティに属する他のエンティティに知らせ、このマルティキャストに対してレスポンスを返したエンティティからポリシーファイルを受け取るものであり、ポリシーファイルを簡単、かつ安全に分配することができる。このように分配されたポリシーファイルを用いて、コミュニティ内の各エンティティが同じポリシーで認証・認可を行うことによって、別の認証・認可サーバなしでも、高いレベルの認証・認可仕組みを実現することが可能になる。

なお、上述ではポリシーファイル自体の形式については特に述べていないが、この発明によるポリシーファイルの分配方法は、特定のポリシーファイルのフォーマットに限らず、いかなるフォーマットのポリシーファイルを配る際にも適用できる。例えば、最近よく使われているポリシーフォーマットは、OASISが定義したXACMLである。このXACML [XACML]のポリシーファイルも本発明の分配技術でコミュニティメンバーに配ることができ、各エンティティは自分の持っているXACML評価モジュールによって、リソースアクセスに対した認証・認可を行うことが可能になる。

この発明は、仮想的に結ばれたコミュニティに属する各エンティティに同じポリシーファイルを分配する際に適用できる。

プッシュモードとプルモードを説明するための図である。 ポリシーパッケージの例を示す図である。 プッシュモードの概要を説明するための図である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（管理者がエンティティＡにＩＮＩＴメッセージを送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（エンティティＡがエンティティＢ，Ｇ，ＬにＤＩＳＴメッセージを送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（エンティティＢ，Ｇ，Ｌが各エンティティリストのエンティティにＵＰＬＯＡＤメッセージを送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（エンティティＢ，Ｇ，ＬがＲＥＰＯＲＴメッセージをメッセンジャノードＡに送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（エンティティＡが残りのエンティティに分配を行うためエンティティＥにＤＩＳＴメッセージを送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（エンティティＥが残りのエンティティＦ，Ｈ，ＮにＵＰＬＯＡＤメッセージを送る）である。 プッシュモードによるポリシーパッケージの分配例を説明するための図（サブメッセンジャノードＥがＲＥＰＯＲＴメッセージをメッセンジャノードＡに送る）である。 シークエンスダイヤグラム（管理者とメッセンジャノード間のやり取り）を示す図である。 シークエンスダイヤグラム（メッセンジャノードとサブメッセンジャノード間、およびサブメッセンジャノードと普通のエンティティ間のやり取り）を示す図である。 プルモードによるポリシーパッケージの分配例を説明するための図（エンティティＨがPDRequestメッセージをマルティキャストで送る）を示す図である。 プルモードによるポリシーパッケージの分配例を説明するための図（サブネットにあるエンティティからPDResponsetメッセージが返ってくる）を示す図である。 プルモードによるポリシーパッケージの分配例を説明するための図（PDResponsetメッセージを送ってくれたエンティティの中の一つのエンティティからポリシーパッケージをダウンロードする）を示す図である。 プルモードによるポリシーパッケージの分配例を説明するための図（ポリシーパッケージのダウンロードが終わったことを、メッセンジャノードに通知する）である。 プルモードのシーケンスダイアグラムを示す図である。

Claims (5)

1. 仮想的に結ばれたコミュニティに属する各エンティティに同じポリシーファイルを分配する方法であって、
   上記コミュニティを管理する管理者は、上記ポリシーファイルおよび該ポリシーファイルを配るエンティティが記載されたエンティティリストを、上記コミュニティに属する所定のエンティティであるメッセンジャノードに送り、
   上記メッセンジャノードは、上記エンティティリストに基づき、上記コミュニティに属する他のエンティティに上記ポリシーファイルを分配し、
   上記メッセンジャノードは、上記エンティティリストに含まれるエンティティ数が所定数より多いときは、該エンティティリストを複数のエンティティサブリストに分割し、該複数のエンティティサブリストをそれぞれ該エンティティサブリストに含まれる所定のエンティティであるサブメッセンジャノードに、上記ポリシーファイルと共に配り、
   上記サブメッセンジャノードは、上記エンティティサブリストに基づき、該エンティティサブリストに含まれるエンティティに上記ポリシーファイルを配り、分配状況を上記メッセンジャノードに報告する
   ポリシーファイルの分配方法。
2. 上記メッセンジャノードは、上記コミュニティに属する他のエンティティに対する上記ポリシーファイルの分配情報をアップデートしながら分配が終了するまで上記ポリシーファイルの分配を管理する
   請求項１に記載のポリシーファイルの分配方法。
3. 上記コミュニティに新たに参加するエンティティは、該参加をマルティキャストで上記コミュニティに属する他のエンティティに知らせ、該マルティキャストに対してレスポンスを返したエンティティから上記ポリシーファイルを受け取り、該受け取りを上記メッセンジャノードに知らせる
   請求項１に記載のポリシーファイルの分配方法。
4. 上記コミュニティに新たに参加するエンティティは、上記マルティキャストに対してレスポンスを返したエンティティが複数存在するとき、到着が最も早いレスポンスを返したエンティティから上記ポリシーファイルを受け取る
   請求項３に記載のポリシーファイルの分配方法。
5. 仮想的に結ばれた複数のエンティティからなり、各エンティティは同じポリシーファイルを用いて所定のリクエストに対して認証・認可を行うコミュニティシステムであって、
   上記管理者は、上記各エンティティに上記ポリシーファイルを分配する際、該ポリシーファイルおよび該ポリシーファイルを配るエンティティが記載されたエンティティリストを、上記複数のエンティティのうち所定のエンティティであるメッセンジャノードに配り、
   上記メッセンジャノードは、上記エンティティリストに基づき、上記コミュニティに属する他のエンティティに上記ポリシーファイルを分配し、
   上記メッセンジャノードは、上記エンティティリストに含まれるエンティティ数が所定数より多いときは、該エンティティリストを複数のエンティティサブリストに分割し、該複数のエンティティサブリストをそれぞれ該エンティティサブリストに含まれる所定のエンティティであるサブメッセンジャノードに、上記ポリシーファイルと共に配り、
   上記サブメッセンジャノードは、上記エンティティサブリストに基づき、該エンティティサブリストに含まれるエンティティに上記ポリシーファイルを配り、分配状況を上記メッセンジャノードに報告する
   コミュニティシステム。
   

Images