BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Integration > B2B トピック > B2B Integration セキュリティの実装 > トレーディング パートナの認証と認可 |
B2B Integration セキュリティの実装
|
トレーディング パートナの認証と認可
ここでは、以下の内容を取り上げます。
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 でのトレーディング パートナの証明書検証
証明書検証プロバイダの実装 証明書検証プロバイダ(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 アプリケーションが実装しなければならない以下のメソッドがあります。
このメソッドは、このインタフェースを実装するクラスのカスタム初期化プロセスを呼び出すために B2B エンジンによって自動的に呼び出されます。このメソッドは、WebLogic Integration の起動時にのみ呼び出されます。
このメソッドは、SSL ハンドシェークで取得した証明書チェーンを検証します。このメソッドは、以下の String 値のいずれかを返します。
インプリメンタは、このメソッドによる検証手順を選択することができます。たとえば、ファイルに格納されている証明書失効リスト(CRL)をチェックする、OCSP (Online Certificate Status Protocol) 使用してリアルタイムで証明書のステータスをチェックする、その他のメカニズムを使用するといった使い方の中から必要に応じて選択できます。
注意: 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 によって制御されます。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |