BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索

B2B Integration セキュリティの実装

 前 次 目次 索引 PDFで表示  

トレーディング パートナの認証と認可

ここでは、以下の内容を取り上げます。

 


WebLogic Integration でのトレーディング パートナの認証

認証とは、WebLogic Integration B2B エンジンがプリンシパルのアイデンティティを確立するプロセスのことです。トレーディング パートナと WebLogic Integration 間では、相互認証(HTTPS)を行う SSL プロトコル経由でデジタル証明書を使用します。B2B エンジンは、リポジトリ内のセキュリティ情報に照らしてデジタル証明書を調べて検証します。

WebLogic Integration B2B には、2 つのレベルの認証プロセスが組み込まれています。

トレーディング パートナのビジネス メッセージがどちらのレベルの認証にも合格すると、B2B エンジンはビジネス メッセージに対する認可プロセスを実行します。

以下の節では、2 つのレベルの B2B 認証プロセスについて説明します。

トレーディング パートナの証明書の検証

WebLogic Integration B2B のセキュリティ モデルでは、SPI (Service Provider Interface: サービス プロバイダ インタフェース) が提供されます。このインタフェースを使用すると、トレーディング パートナの証明書を検証するためのサードパーティのサービスを呼び出すインタフェースを実装する Java クラスを組み込むことができます。こうした CVP (Certificate Verification Provider: 証明書検証プロバイダ) と呼ばれる実装では、以下のいずれかの証明書検証アプリケーションを呼び出せます。

証明書検証の利点

トレーディング パートナの証明書検証の目的は、トレーディング パートナのデジタル証明書の有効性を検証することです。たとえば、証明書の検証では、以下のタスクの一部またはすべてを実行します。

CVP の実装のコンフィグレーションおよび使用は省略可能ですが、使用すると、証明書検証プロセスでより高いレベルのセキュリティを提供できます。

証明書検証プロセス

次の図は、WebLogic Integration 環境の証明書検証プロセスのイベント タスク順序を示しています。

図2-1 WebLogic Integration でのトレーディング パートナの証明書検証


 

上の図の以下の番号に注目してください。

番号

説明

1

証明書検証は、SSL を使用した場合にのみ実行される。トレーディング パートナと WebLogic Server システムは SSL ハンドシェークを実行し、その中で証明書を交換し、互いのアイデンティティを確立する。トレーディング パートナのデジタル証明書の認証局は、WebLogic Server で信頼されている必要がある。ハンドシェークでは、WebLogic Server は以下の点を検証する。

SSL ハンドシェークが終了すると、トレーディング パートナと WebLogic Server システムとのネットワーク接続が確立される。

2

WebLogic Server は、B2B エンジンの WLCCertAuthenticator クラスを呼び出す。WLCCertAuthenticator クラスは、トレーディング パートナの証明書をトレーディング パートナに対してコンフィグレーションされている WebLogic Server ユーザにマップするために、weblogic.security.acl.CertAuthenticator インタフェースを実装する。

3

WLCCertAuthenticator クラスは、サードパーティの証明書検証サービスを呼び出す実装の CVP インタフェースを呼び出す。

4

CVP の実装は、トレーディング パートナの証明書のステータスを返すサードパーティの証明書検証サービスを呼び出す。

5

CVP の実装は、証明書のステータスを WLCCertAuthenticator クラスに返す。

6

トレーディング パートナの証明書が有効な場合、B2B エンジンは証明書をリポジトリの有効なトレーディング パートナ名にマップしようとする。証明書が有効なトレーディング パートナにマップされると、WebLogic Integration は WebLogic Server ユーザを WebLogic Server に返す。


 

証明書検証プロバイダの実装

証明書検証プロバイダ(CVP) Java クラスは、com.bea.b2b.security.CertificateVerificationProvider インタフェースを実装しています。CVP クラスは、以下の 2 種類を呼び出すことができます。

どちらを呼び出す場合でも、実際に証明書を検証するアプリケーションを呼び出す CVP SPI の Java 実装を作成する必要があります。ここからは、この CVP アプリケーションの作成、コンパイル、およびコンフィグレーションについて説明します。

サービス プロバイダ インタフェースの使い方

WebLogic Integration B2B では、CVP のサービス プロバイダ インタフェース(SPI)を提供する com.bea.b2b.security.CertificateVerificationProvider インタフェースを介して CVP を実装できます。ここで説明する SPI を使用して CVP を実装または使用する場合、CVP が実行時に正しく呼び出されるように、WebLogic Integration B2B Console で CVP をコンフィグレーションする必要があります。

com.bea.b2b.security.CertificateVerificationProvider インタフェースには、CVP アプリケーションが実装しなければならない以下のメソッドがあります。

注意: CVP を実装する場合、引数を持たない CVP のデフォルト パブリック コンストラクタを追加する必要があります。クラス内のコンストラクタもメソッドも、例外を送出してはなりません。

CVP をコンフィグレーションしない場合、B2B エンジンは、信頼性のある認証局によって発行されたすべての証明書を有効であると見なします。

証明書検証プロバイダ クラスのコンパイル

CVP を実装する場合は、以下の点に注意します。

WebLogic Integration B2B での証明書検証プロバイダのコンフィグレーション

B2B Console を使用して CVP をコンフィグレーションする手順については、証明書検証プロバイダ インタフェースのコンフィグレーションを参照してください。CVP をコンフィグレーションしたら、CVP を有効にするために WebLogic Server を再起動します。

トレーディング パートナのメッセージの認証

トレーディング パートナの証明書が WebLogic Server によって認証されたら、B2B エンジンは、メッセージ自体を処理する前にトレーディング パートナのメッセージを認証する必要があります。トレーディング パートナのメッセージの認証では、ビジネス メッセージの送信元が WebLogic Integration リポジトリのリストに入っている有効なトレーディング パートナであることを検証します。トレーディング パートナのメッセージが認証されると、そのトレーディング パートナのアイデンティティが認められ、B2B リソースに完全にアクセスできるようになります。

次の図は、トレーディング パートナのメッセージの認証プロセスを示しています。

図2-2 トレーディング パートナのメッセージの認証


 

上の図の以下の点に注目してください。

注意: トレーディング パートナだけが B2B 転送サーブレットを使用するための認証の対象となります。B2B システム ユーザが B2B リソースにアクセスするために転送サーブレットにアクセスしようとした場合、WebLogic Server によってアクセスが拒否されます。このメカニズムによって、B2B システム ユーザを装ったリモート エンティティが B2B リソースにアクセスすることはできなくなります。

 


WebLogic Integration B2B でのトレーディング パートナの認可

認可とは、B2B プリンシパルに B2B リソースの特定のセットへのアクセスを許可するプロセスのことです。B2B システムの認可モデルは、ACL およびパーミッション メカニズムとロールベースの認可制御に基づいています。

B2B システムには、2 つのレベルの認可が組み込まれています。

トレーディング パートナの認可

このレベルの認可は、WebLogic Server によって実行されます。トレーディング パートナのメッセージが WebLogic Server に到着すると、トレーディング パートナと WebLogic Server は相互認証手順を実行し、トレーディング パートナは認可され、B2B 転送サーブレットにアクセスできるようになります。

転送サーブレットのパスは一定ではないので、トレーディング パートナが転送サーブレットの URL にアクセスできるように web.xml ファイルを編集する必要があります。転送サーブレットに対応する URL が B2B 環境に合わせて変化するという性質を持っているので、これを事前にコンフィグレーションすることはできません。

転送サーブレットの ACL を web.xml ファイルに指定する必要があります。次の例は、wlctransport という転送サーブレットの ACL を指定する web.xml ファイルです。

コード リスト 2-1 転送サーブレットの ACL の例

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 1.2//EN
" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>
...
...
<!-- Authentication -->
<security-constraint>
<web-resource-collection>
<web-resource-name>wlctransport</web-resource-name>
<url-pattern>*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>TradingPartnerGroupA</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>CLIENT_CERT</auth-method>
</login-config>

<security-role>
<role-name>TradingPartnerGroupA</role-name>
</security-role>
</web-app>

上のコードについて以下で説明します。

会話認可

B2B エンジンが会話認可を実行する場合、サーバは、トレーディング パートナがバインドされているコラボレーション アグリーメントに関するトレーディング パートナのビジネス メッセージの内容を調べます。つまり、コラボレーション アグリーメントで指定された特定のロールおよびパーティに対しては、トレーディング パートナは特定のビジネス メッセージのセットしか送信できません。B2B エンジンは、特定の会話に関するコラボレーション アグリーメントに指定された以下の情報と照らしてビジネス メッセージを検証します。

受け取ったビジネス メッセージに関する会話認可が終了すると、B2B リソースに対するアクセスは ACL によって制御されます。

 

ページの先頭 前 次