ヘッダーをスキップ
Oracle BPEL Process Manager 管理者ガイド
10g(10.1.3.1.0)
B31875-02
  目次
目次
索引
索引

戻る
戻る
次へ
次へ
 

1 Oracle BPEL Process Managerのセキュリティ

BPELプロセスや、これらのプロセスにより使用されるWebサービスへのアクセスを制御することは非常に重要です。プロセスの完全性と、カスタマの個人情報の両方を保護するためには、認可されていないユーザーによるシステムへの侵入を防ぐ必要があります。この章では、Oracle BPEL Process Managerを使用してBPELプロセスを保護し、保護されたWebサービスを呼び出す方法について説明します。

この章で説明する内容は次のとおりです。

1.1 セキュリティの概要

Oracle BPEL Process Managerのセキュリティは、次のように実装されます。

図1-1は、BPELプロセスを保護し(インバウンド)、保護されたサービスを呼び出す(アウトバウンド)ための転送セキュリティおよび認証方式の概要を図に表したものです。

図1-1インバウンドおよびアウトバウンドの転送セキュリティと認証方式

bpmag002.gifの説明が続きます
図bpmag002.gifの説明

この項では、Oracle BPEL Process Managerに関連する次のセキュリティ機能の概要について説明します。また、これらの機能の詳細が説明された参照先も併記します。

1.1.1 WS-Security

WS-Securityでは、Simple Object Access Protocol(SOAP)メッセージに3つのレベルのセキュリティを追加するためのメカニズムが提供されます。これらのセキュリティ・レベルは次のとおりです。

  • 認証トークン: SOAPメッセージ・ヘッダー内で、ユーザー名、パスワード情報およびX.509証明書を渡すために使用されます。

  • XML暗号化: メッセージの機密を保護するために使用されます。

  • XML電子署名: メッセージの完全性の確保、ソースおよびオリジナルの検証、否認防止などのために使用されます。


関連項目:


1.1.2 認証

認証は、ユーザーの識別情報を確認するプロセスです。Oracle BPEL Process Managerでは、Basic認証(HTTP)、証明書をベースとした認証(HTTP/S)、およびネイティブのBPELセキュリティ拡張認証がサポートされています。


関連項目:

次の項を参照してください。

1.1.3 認可

認可は、メッセージの送信やリクエストの作成に対するセキュリティ制約の評価です。認可では、リクエストを許可するかどうかを判断するために固有の基準が使用されます。これらの基準は認証と制約です。現在のところ、Oracle BPEL Process Managerでは、インバウンド認証はサポートされていません。そのかわり、Oracle Web Services Managerにより、この機能が提供されます。


関連項目:

「認可」

1.1.4 暗号化と復号

暗号化は、対象となる受信者のみがデータをデコード(復号)して解読できるように、エンコード(暗号化)することです。現在のところ、Oracle BPEL Process Managerでは、XML暗号化はサポートされていません。そのかわり、Oracle Web Services Managerにより、この機能が提供されます。

1.1.5 Secure Sockets Layer(SSL)

Secure Sockets Layer(SSL)は、HTTP/S(セキュアHTTP)を使用して、インターネット経由で文書を安全に送信するための標準です。SSLでは、データの漏洩を防ぐために電子署名が使用されます。


関連項目:


1.1.6 完全性と否認防止のための電子署名

電子署名は電子文書に添付されたコードで、作成者や送信者を確実に識別し、この文書が漏洩していないことを証明するものです。現在のところ、Oracle BPEL Process Managerでは、電子署名はサポートされていません。そのかわり、Oracle Web Services Managerにより、電子署名や署名検証機能が提供されます。


関連項目:

「電子署名」

1.1.7 BPELセキュリティ拡張機能

BPELセキュリティ拡張機能は、Oracle BPEL Process Managerに完全に統合されています。

HTTP、SOAP、Java APIなど、プロセスの呼出しにどのチャネルを使用するかに関係なく、同じセキュリティ制約が適用されます。ただし、資格証明の渡し方はチャネルによって異なります。

BPELセキュリティ拡張機能は、Oracle BPEL Process Managerのセキュリティ強化を希望するBPEL開発者を対象としています。これらの拡張機能は専門的であり、プロセスの呼出しに使用されている各種テクノロジ(SOAPやHTTPなど)を含め、Oracle BPEL Serverについて理解している必要があります。また、Oracle BPEL Java APIを使用することも多いため、Javaについての十分な知識も必要です。

Oracle BPEL Process ManagerのAPIには、開発者によるカスタム・セキュリティの作成を可能にするBPELセキュリティ拡張機能があります。BPELプロセスの使用にユーザーの認証および認可が必要な、保護された環境下では、この機能が必須です。

1.2 BPELプロセスの保護(インバウンド)

Oracle BPEL Serverに送信されたインバウンド・クライアントのサービス・リクエストにより相互作用が開始される、BPELプロセスを保護できます。

図1-2は、BPELプロセスを保護する(インバウンド)ための転送セキュリティおよび認証方式の概要を、高いレベルから図に表したものです。

図1-2 BPELプロセスの保護(インバウンド)

bpmag004.gifの説明が続きます
図bpmag004.gifの説明

この項では、次の機能を使用して、BPELプロセス・セキュリティを確保する方法について説明します。


注意:

1つ以上のサーバー・インスタンスをビジネス・プロセスのセキュリティ保護専用とし、その他のインスタンスを保護されていないプロセスのホスト用に設定した環境の作成をお薦めします。

1.2.1 証明書ベースの認証におけるSSLの使用

BPELプロセスは通常、SOAP over HTTPを使用して呼び出されます。Basic認証では、認証されたユーザーのみがBPELプロセスにアクセスできますが、一方、ユーザー名やパスワードはネットワーク・パケット・スニファにより傍受されることがしばしばです。したがって、HTTPではなくHTTP/Sを使用して、ネットワーク接続を保護する必要があります。認証スキーマとしてHTTP/Sを使用すると、クライアントとサーバーの両方で証明書を交換するように構成できます。正常なSSLハンドシェイクにより、認証が確認されます。

使用できる証明書認証の種類は次のとおりです。

  • サーバー証明書認証

    このシナリオでは、クライアントはサーバーに証明書を要求し、このサーバーが信頼できるかどうかを認証します。クライアントは、サーバーからのリクエストがなければ自身の証明書は提示しません。証明書を提示するサーバーの種類は、使用しているOracle BPEL Process Managerのインストール・タイプによって次のように異なります。

    • Oracle BPEL Process Manager for OracleAS Middle Tierでは、サーバーはOracle Application Server(およびそのバージョンのOC4J)です。

    • Oracle BPEL Process Manager for Developersでは、サーバーはOracle BPEL Process ManagerがデプロイされているスタンドアロンOC4Jです。

  • サーバーおよびクライアント証明書認証

    このシナリオでは、クライアントとサーバーの両方が証明書を交換し、正常なSSLハンドシェイクにより認証が確認されます。これはクライアント認証モードと呼ばれます。サーバー(Oracle BPEL Process ManagerがデプロイされているOC4J、またはOracle Application Server(およびそのバージョンのOC4J)のいずれか)は、SSLハンドシェイク中にクライアントの証明書をリクエストし、クライアントの信頼性を認証するように構成される必要があります。BPELプロセスのセキュリティ保護の観点では、これはサービスを呼び出しているクライアントが、双方が信頼している認証局により発行された有効な証明書を提示することを意味します。サーバーとクライアントの証明書による認証は、それほど頻繁に使用されません。

次の項では、Oracle BPEL Process Managerのインストール・タイプ別にSSLを構成する方法について説明します。

1.2.1.1 Oracle BPEL Process Manager for OracleAS Middle Tier

Oracle BPEL Process Manager for OracleAS Middle TierのSSL構成には、次の2つの手順を実行します。

1.2.1.1.1 ステップ1: OC4Jの構成

Oracle BPEL Process Manager for OracleAS Middle Tierインストール・タイプで証明書ベースの認証を有効にするには、Oracle Wallet Managerを使用します。(図1-2を参照。)Oracle Wallet Managerは、Oracle Walletでセキュリティ資格証明の管理と編集を行うためのアプリケーションです。ウォレットはパスワードで保護されたコンテナで、その中には秘密鍵や証明書、信頼できる証明書などの認証および署名された資格証明が格納されています。これらはすべて、厳密な認証を行うためにSSLにより使用されます。


注意:

Oracle Walletに付属する、testという名前のデフォルトの証明書は使用しないでください。デフォルトの証明書では、正式なサーバー・ホスト名が使用されません。かわりに、認証局から証明書を取得してください。この証明書のCNエントリには、適切なサーバー・ホスト名が必要です。


関連項目:

次のSSL構成の詳細は、『Oracle Application Server管理者ガイド』を参照してください。
  • ウォレットの設定およびOracle Wallet Managerの使用

  • 認証局からの証明書の入手


1.2.1.1.2 ステップ2: Oracle BPEL Serverの構成

Oracle BPEL Serverは、SOAPサーバーURLとSOAPコールバックURLを使用して構成する必要があります。

  1. Oracle BPEL Admin Consoleにログインします。

    http://localhost:port/BPELAdmin
    
    
  2. ユーザー名oc4jadminおよびパスワードを入力します。

  3. 「構成」タブにある次の2つのパラメータを設定します。

    パラメータ 説明
    soapServerUrl プロセスのBPEL SOAPサーバーのエンドポイントURL http://hostname:port
    soapCallbackUrl プロセスのBPEL SOAPコールバックURL http://hostname:port

  4. SOA_Oracle_Home¥bpel¥domains¥domain_name¥tmpにあるデフォルトの.bpel_TaskManager_1.0.jarディレクトリと.bpel_TaskActionHandler_1.0.jarディレクトリを削除します。

    ここでのdomain_nameは、セキュリティ保護の対象となるBPELプロセスの存在するドメインの名前です。

  5. Oracle BPEL Serverを再起動します。

    これにより、TaskManagerプロセスとTaskActionHandlerプロセスの正しいサーバー・バインディングおよびWSDLファイルが再作成され、HTTP/Sベースのエンドポイントからの使用が可能になります。Oracle BPEL Process Managerにデプロイされたプロセスは、新しいHTTP/Sエンドポイントで安全にホストされます。

1.2.1.2 Oracle BPEL Process Manager for Developers

Oracle BPEL Process Manager for DevelopersのSSL構成には、次の2つの手順を実行します。

1.2.1.2.1 ステップ1: OC4Jの構成

  1. 次に示すSSL構成の手順については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。

    • keytoolを使用して、証明書ベースの認証を有効にします。このツールはキーストアと、自己署名証明書を生成します。キーストアは保護されたデータベースであり、企業で利用する鍵や証明書を格納しています。キーストアへのアクセスはパスワードで保護されています。パスワードは、キーストアを作成したユーザーにより、キーストアの作成時に定義されたもので、現在のパスワードを入力した場合のみ変更可能です。

    • SSLを使用するようにOC4Jを構成します。完了すると、OC4Jは1つのポートでSSLリクエストを、別のポートで非SSLリクエストをリスニングするようになります。


注意:

  • SSLを構成した後に必ずOC4Jを停止し、再起動してください。このためには、Oracle BPEL Serverを停止し、再起動します。

  • 本番環境での自己署名証明書のかわりに、keytoolにより生成された証明書リクエストを送信し、Verisign、Thawteなどの信頼できる認証局から発行された証明書を使用します。


1.2.1.2.2 ステップ2: Oracle BPEL Serverの構成

Oracle BPEL Server for the Oracle BPEL Process Manager for Developersインストール・タイプを構成する手順は、Oracle BPEL Process Manager for OracleAS Middle Tierインストール・タイプを構成する手順と同じです。

Oracle BPEL Serverを構成する手順については、「ステップ2: Oracle BPEL Serverの構成」を参照してください。

1.2.2 J2EEのBasic認証の使用

J2EEのBasic認証には、署名のないトークン、つまりユーザー名およびパスワードによる認証が含まれます。

表1-1は、この方式でサポートされている機能を説明したものです。

表1-1 J2EEのBasic認証でサポートされている機能

認証スキーマ サービス・アクセス・プロトコル ユーザー・リポジトリ 許可されているカスタマイズ 粒度
Basic認証(ユーザー名およびパスワード) HTTPのみ Oracle Application Server JAZNリポジトリ・タイプ:
  • OID

  • JAZN XML

  • JAASカスタム・プラグイン

JAASカスタム認証プラグイン 個々のプロセス・レベルのセキュリティ

次の項では、Oracle BPEL Process Managerのインストール・タイプ別に使用する構成方法について説明します。

1.2.2.1 Oracle BPEL Process Manager for OracleAS Middle Tier

Oracle BPEL Process Manager for OracleAS Middle Tierインストール・タイプでのJ2EEのBasic認証には、Oracle Application Serverへの認証委任が含まれます。(図1-2を参照。)このプロセスのフローを次に示します。

  1. Oracle HTTP Serverにより、サービス・リクエストが受信されます。

  2. Oracle HTTP Serverにより、このリクエストがOC4Jに転送されます。

  3. OC4Jでは、受信したHTTPヘッダーに含まれるユーザー名およびパスワードが次の構成済IDサービス・ユーザー・リポジトリと照合され、正当性が確認されます。

    • Oracle Internet Directory(OID)

    • Oracle Application ServerのJava Authentication and Authorization Service (JAAS) Provider (JAZN) XML

    • JAASカスタム・プラグイン

  4. ユーザー名およびパスワードが認証されると、リクエストはOracle BPEL Serverに送信されサービスが提供されます。


    関連項目:

    構成の手順については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。

1.2.2.2 Oracle BPEL Process Manager for Developers

Oracle BPEL Process Manager for Developersインストール・タイプでのJ2EEのBasic認証には、Oracle BPEL Process ManagerがデプロイされているOC4Jへの認証委任が含まれます。(図1-2を参照。)このプロセスのフローを次に示します。

  1. JAZNリポジトリで新たにユーザーとロールを設定します。

    たとえば、JAZN XMLのユーザーについて、次のように、SOA_Oracle_Home¥bpel¥system¥appserver¥oc4j¥j2ee¥home¥config¥system-jazn-data.xmlで新しいユーザーとロールを構成します。

    <user>
       <name>jsmith</name>
       <credentials>{903}9XRK6pyPRTVYN7bW5dkG1Z06C2pkBRW6</credentials>
    </user>
    . . .
    . . .
    <role>
       <name>jsmithrole</name>
       <members>
          <member>
            <type>user</type>
            <name>jsmith</name>
          </member>
       </members>
    </role>
    
    
  2. SOA_Oracle_Home¥bpel¥system¥appserver¥oc4j¥j2ee¥home¥applications¥orabpel_ear¥META-INF¥orion-application.xmlファイルを構成します。

    次のセクションを追加して、OC4Jに保持されている物理的なセキュリティ・ロール(たとえば、JAASプリンシパルとレルム)を論理的なJ2EEグループやユーザーにマップします。

    <security-role-mapping name="jsmithrole">
       <group name=" jsmithrole" />
    </security-role-mapping>
    
    
  3. BPELサービス・エンドポイントURLを保護するために、SOA_Oracle_Home¥bpel¥system¥appserver¥oc4j¥j2ee¥home¥applications¥orabpel_ear¥startup_war¥WEB-INF¥web.xmlファイルを構成します。

    web.xmlにおいて、エンドポイントURL(http://localhost/orabpel/default/HelloWorld/1.0)を保護するコード・セグメントは次のとおりです。

    <security-constraint>
       <web-resource-collection>
          <web-resource-name>Default Domain Pages</web-resource-name>
          <description>These pages are only accessible by authenticated
             users.</description>
          <url-pattern>*/orabpel/default/HelloWorld/1.0</url-pattern>
          <url-pattern>*/orabpel/default/HelloSecureWorld/1.0</url-pattern>
       </web-resource-collection>
       <auth-constraint>
          <role-name>jsmithrole</role-name>
       </auth-constraint>
    </security-constraint>
    <login-config>
       <auth-method>BASIC</auth-method>
       <realm-name>jazn.com</realm-name>
    </login-config>
    <security-role>
       <description>BPEL PM User</description>
       <role-name>jsmithrole</role-name>
    </security-role>
    

1.2.3 ネイティブのBPELセキュリティ拡張機能の使用

ネイティブのBPELセキュリティ拡張コードを使用すると、認証の処理も可能です。(図1-2を参照。)このプロセスのフローを次に示します。

  1. Oracle HTTP Serverにより、サービス・リクエストが受信されます。

  2. Oracle HTTP Serverによりリクエストが転送されますが、その一部はOracle BPEL Process Managerによりインターセプトされます。

  3. Oracle BPEL Process ManagerのBPELセキュリティ拡張コードは、構成済IDサービス・ユーザー・リポジトリに対して受信メッセージを検証します。

    • OID

    • JAZN XML

    • JAASカスタム・プラグイン

  4. ユーザー名およびパスワードが認証されると、リクエストに対してOracle BPEL Serverによるサービスが提供されます。

表1-2は、この方式でサポートされている機能を説明したものです。

表1-2 ネイティブのBPELセキュリティ拡張機能でサポートされている機能

認証スキーマ サービス・アクセス・プロトコル ユーザー・リポジトリ 許可されているカスタマイズ 粒度
Basic認証(ユーザー名およびパスワード) HTTP Oracle Application Server JAZNリポジトリ・タイプ:
  • OID

  • JAZN XML

  • データベースをベースにしたリポジトリ

  • カスタム

カスタム・バリデータ・クラスを使用したカスタム・ユーザー・リポジトリ

関連項目: 「カスタム・バリデータの作成」

きめ細かい:
  • 個々のプロセス・レベルのセキュリティ(たとえば、username1/password1を使用するservice1username2/password2を使用するservice2

  • ドメイン・レベルの保護、および各ユーザー名とパスワードに対応する、そのドメイン内のサービスすべてをサポート

正規化されたメッセージ・プロパティ
  • Java API
  • Remote Method Invocation(RMI)




WS-Security(Web Services Security仕様に従う) SOAP



この項で説明する内容は次のとおりです。

1.2.3.1 ドメインおよびプロセス・レベルのセキュリティ

Oracle BPEL Serverでは、インバウンド(Oracle BPEL Serverへの呼出し)メッセージ・フロー、およびアウトバウンド(Oracle BPEL Serverからの呼出し)メッセージ・フローの制御や修正に、メッセージ・ハンドラ・フレームワークが使用されます。セキュリティ・インタセプタは、このようなプラグイン・ハンドラの1つです。セキュリティ・インタセプタでは、次の2つのレベルのセキュリティが提供されます。

  • ドメイン・レベルのセキュリティ

    このレベルのみが設定されている場合、特定のドメインで実行されているすべてのプロセスのセキュリティを保護できます。

  • プロセス・レベルのセキュリティ

    このレベルも設定されている場合、特定のドメインで保護するプロセスと保護しないプロセスを指定できます。


注意:

次の項では、フレームワーク自体ではなく、セキュリティ・インタセプタの構成についてのみ説明しています。

デフォルトでは、ドメインおよびプロセスのセキュリティは有効になっていません。しかし、SOA_Oracle_Home¥bpel¥domains¥domain_name¥config¥message-handlers.xmlファイルを変更することにより、どちらのセキュリティ・レベルも簡単に有効化できます。

  1. ドメイン・レベルのセキュリティを有効化するには、security属性を囲んでいる太字のコメント・マーカーを削除します(この例では、ドメインの名前はdefaultです)。

    <inbound-flow>
       <message-handler id="default" />
    
    <!-- uncomment for inbound security
        <message-handler id="security" />
    -->
    
    </inbound-flow>
    
    

    これにより、次のセキュリティ・チェーンが有効になります。

    <message-handler id="security">
            <classname>com.collaxa.cube.security.Authenticator</classname>
            <comment>
               <![CDATA[This is the handler for security interception]]>
               </comment>
            <property id="ACLManager">
                <value>com.oracle.bpel.security.validator.bpmid.
                  BPMIdentityValidator</value>
            <comment>BPMIdentityValidator uses the server configured security
                     such as JAAS to validate the user against</comment>
            </property>
    <!--
       <property id="SecuredProcesses">
          <value>CreditRatingService</value>
             <comment>Processes can be secured explicitely without having effect
                 on the whole domain, put their names in here and comma
                 separate them
             </comment>
       </property>
    -->
    </message-handler>
    
    
  2. さらに、プロセス・レベルのセキュリティも有効化するには、同じファイルからSecuredProcesses属性を囲んでいる太字のコメント・マーカーを削除します。このセクションには、プロセス名のカンマ区切りリストから構成されるvalueが含まれます。

    <!--
       <property id="SecuredProcesses">
          <value>CreditRatingService</value>
             <comment>Processes can be secured explicitely without having
                effect on the whole domain, put their names in here and comma
                separate them</comment>
       </property>
    -->
    
    </message-handler>
    
    
  3. SecuredProcessesセクションのvalue要素に、保護するプロセスを指定します。次に例を示します。

    <value>CreditRatingService, HelloWorldService</value>
    
    

    このドメインで、value要素に指定されていないプロセスは保護されません。

  4. Oracle BPEL Serverを再起動します。

    これにより、認証および認可で使用されるデフォルトのバリデータ・ブリッジが有効化されます。


関連項目:

バリデータ・ブリッジについては、「デフォルト・バリデータの使用」を参照してください。

1.2.3.2 Java API

プロセスの呼出しには、DeliveryServiceを使用します。ただし、正規化されたメッセージ(com.oracle.bpel.client.NormalizedMessage)には、NormalizedMessage:setProperty(key, value)を使用して、次のプロパティを追加する必要があります。

secured = username
username = password

ここでのusernameは、送信されるユーザー名と同じものです。また、2つ目のペアは、usernameおよび求められる資格証明により構成されます。次に例を示します。

secured = Clemens
Clemens = pwForClemens

注意:

空のパスワードを送信することもできます。この場合、1つ目のペアのみを追加します。
secured = Clemens

1.2.3.3 HTTPバインディング

直接HTTPバインディングを使用してプロセスを呼び出す場合、資格証明を指定する方法は数種類あります。

  • HTTPリクエスト・パラメータとして指定:

    <input type="hidden" name="bpelUser" value="clemens">
    <input type="hidden" name="bpelCredential" value="clemens">
    
    
  • Basic認証のHTTPヘッダーとして指定(base64エンコード):

    Authentication=BASIC <BASE64-HASH>
    
    
  • 通常の名前/値のHTTPヘッダー・ペアとして指定。ここで、ユーザー・キーはbpelUser、パスワード・キーはbpelCredentialです。

1.2.3.4 SOAP over HTTPバインディング

SOAPバインディングを使用する場合、ユーザー名の資格証明を渡す方法として現在サポートされているのはWS-Security準拠のSOAPヘッダーのみです。次に例を示します。

<wsse:Security soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
               soapenv:mustUnderstand="1"
               xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                  wss-wssecurity-secext-1.0.xsd"
               xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
                  <wsse:UsernameToken
               xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                  wss-wssecurity-utility-1.0.xsd"><wsse:Username>Clemens
                     </wsse:Username><wsse:Password Type=
                        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                         wss-username-token-profile-1.0#PasswordText">pwForClemens
                        </wsse:Password>
                    </wsse:UsernameToken>
</wsse:Security>

Javaを使用してSOAP経由でサービス・エンドポイントをコールする場合、クラスcom.oracle.bpel.client.util.WSSecurityUtilsは、ネームスペースのヘッダー要素を生成できます。次に例を示します。

  /**
   * Create a WSSecurity compliant token from username and password -
 UsernameToken!!
   * @throws javax.xml.soap.SOAPException in case the element cannot be
 constructed
   * @return the headerElement needed for the header of the call
   * @param pCredential the credential
   * @param pUsername the username
   */
  public static SOAPHeaderElement createWSSecurityHeader (String pUsername,
                                                          String pCredential)

createWSSecurityHeaderは古いJava標準に対応しているので注意してください。2004年のWS-Security標準の変更後は、新しいネームスペースを適用する必要があります。適用しない場合、デフォルトのhttp://schemas.xmlsoap.org/ws/2002/07/secextネームスペースが使用されます。新しいネームスペースを使用してWSSEヘッダーを作成するには、WSSecurityUtilsクラスにある次のメソッドを使用します。

public static SOAPHeaderElement createOASISWSSecurityHeader
       (String pUsername,
        String pCredential,
        boolean pIsWSPolicyCompliant) throws SOAPException
  {

1.3 保護されたサービスの呼出し(アウトバウンド)

Oracle BPEL Serverからパートナ・リンクWebサービスが実行されているサーバーに送信されたアウトバウンド・クライアントのリクエストにより相互作用が開始される、保護されたサービスを呼び出せます。保護されたサービスを呼び出すための構成手順は、次に示すOracle BPEL Process Managerのインストール・タイプでの構成手順のいずれかと同じです。

図1-3は、保護されたサービスを呼び出す(アウトバウンド)ための転送セキュリティおよび認証方式の概要を図に表したものです。

図1-3 保護されたサービスの呼出し(アウトバウンド)

bpmag003.gifの説明が続きます
図bpmag003.gifの説明

この項で説明する内容は次のとおりです。

1.3.1 証明書ベースの認証におけるSSLの使用

パートナがHTTP/Sベースのサービスを公開している場合、このサービスのWSDLにはサービス・バインディングの情報が含まれます。サービスは、SOAPまたはHTTPバインディングを持つOracle BPEL Process Managerから呼び出せます。

SSLに対するOracle BPEL Process Managerのサポートは、Java Secure Socket Extension(JSSE)標準をベースにしたもので、暗号化サービスについてはデフォルトのSunJSSEプロバイダに依存しています。キーストアとトラストストアの構成については、Oracle BPEL Process Managerでは標準JSSE keytoolとJSSEメカニズムに依存しています。 (図1-3を参照。)

使用できる証明書認証の種類は次のとおりです。

  • サーバー証明書認証

    SSLハンドシェイク・プロセスにおいて、パートナ・リンク・サーバーの保護されたサービスに対するクライアントとして機能するOracle BPEL Process Managerは、パートナ・リンクの信頼性を検証(サーバー認証)するように要求されます。この要求を満たすには、パートナ・リンク・サーバーの提示する証明書の検証が必要です。このため、Oracle BPEL Process Managerでは、デフォルトのSunJSSE機能が使用されます。また、このプロセスで使用されるトラストストアには適切な証明書エントリが必要です。パートナ・リンク・サーバーで自己署名証明書が使用されている場合、この証明書を信頼できるエントリとしてトラストストアに置く必要があります。パートナ・リンク・サーバーが証明連鎖を提示した場合、この連鎖のルート証明書はトラストストアの一部である必要があります。

  • サーバーおよびクライアント証明書認証

    ハンドシェイク・プロセスにおいて、クライアント(このシナリオではOracle BPEL Process Manager)は、パートナ・リンク・サーバーから、検証用の証明書の提示を要求されることがあります。これはクライアント認証モードと呼ばれます。このような場合、Oracle BPEL Process Manager用に証明書を設定する必要もあります。これは自己署名証明書でも、認証局により提供された証明書でもかまいません。keytoolを使用して、キーストアとトラストストアに証明書と鍵を保存することができます。

    ただし、パートナ・リンク・サービスで証明書が必要とされているかどうかをサービスのWSDLから知ることはできません。この要件はあまり一般的ではありません。

信頼できる証明書エントリを格納するためのトラストストアを設定すると便利です。これは、秘密鍵エントリや公開鍵エントリを格納するためのキーストアとは異なります。

JDKインストールのjre¥lib¥securityディレクトリにあるデフォルトのキーストア・ファイルとトラストストア・ファイルが使用されます。

  • デフォルトのキーストアはcacertsファイルです。

  • jssecacertsファイルが存在していれば、これがトラストストア・ファイルです。jssecacertsが存在しない場合、cacertsはトラストストアとしても使用されます。

キーストア・ファイルとトラストストア・ファイルは、JDKのkeytoolにより作成され、管理されます。このツールは、次のような操作の実行に便利です。

  • 新しいキーストアおよびトラストストアの作成

  • ストアに存在する情報の読込みおよびリストアップ

  • キーストアおよびトラストストアにすでに存在するエントリの更新や削除


注意:

  • クライアントであるOracle BPEL Serverと、パートナ・リンクのWebサービスが実行されているサービスの間で通信を行うためのセキュリティ証明書の作成には、Oracle Wallet Managerを使用しないでください。

  • 保護されたサービスを呼び出す場合、Oracle BPEL Serverの構成は必要ありません。この種類の相互作用では、Oracle BPEL Serverがクライアントであるからです。



関連項目:


1.3.1.1 Oracle JDeveloperの設計時

保護されたWSDLにアクセスするには、Oracle BPEL Serverと同様、Oracle JDeveloperも設計時に構成する必要があります。

1.3.1.2 Oracle BPEL Serverランタイム

この項では、パートナ・リンクのWebサービス・サーバー、およびOracle BPEL Serverのクライアント側証明書を使用してHTTP/Sを構成する方法について説明します。

1.3.1.2.1 パートナ・リンク・サーバー証明書認証のみを使用したHTTP/S

この環境で、Oracle BPEL Process Managerを構成するには、次のようにします。

  1. 双方が信頼している証明書、またはパートナ・リンクのサーバー証明書を呼び出せるように、キーストアが適切に構成されていることを確認します。

    1. Webブラウザを使用して、呼び出すサービスのエンドポイントURLに接続します。サーバーへの接続が完了すると、ポップアップ・ウィンドウに次のメッセージが表示されます(この証明書を使用してブラウザのストアをまだ更新していない場合)。

      Security Alert: Do you trust this certificate or not?
      
      
    2. このサーバー証明書を信頼しているので、yesと入力します。

      Internet Explorerにページが読み込まれると、ブラウザ・ウィンドウの右下隅、ステータス・バーの上に錠が表示されます。

    3. この錠をクリックします。ウィンドウが開き、証明書に関する詳細が表示されます。

    4. 「詳細」タブをクリックし、証明書を(たとえば、TestServiceServerCert.cerという名前の)ファイルにコピーします。base64エンコード形式が使用できます。

    5. このファイルを使用して、デフォルトのトラストストアにサーバー証明書をインポートします。これにはkeytoolを使用すると便利です。

    6. デフォルトのトラストストアとキーストアが同一である場合に、この証明書をデフォルトのcacertsキーストアにインポートするためのコマンドは次のとおりです。

      SOA_Oracle_Home\jdk\bin\keytool -import -v -file TestServiceServerCert.cer
       -keypass keystore_password -keystore cacerts
      
      
    7. パートナ・リンク・サーバーのサーバー証明書を格納する必要がない場合は、使用しているトラストストア、またはキーストアに双方が信頼しているルートおよび認証局証明書が入っていることを確認できます。

  2. OC4J、およびOracle BPEL Process Managerにより、正しいキーストアが使用されていることを確認します。

    使用しているキーストアが、SOA_Oracle_Home¥jdk¥jre¥lib¥securityディレクトリ内のデフォルトのcacertsファイル・キーストアである場合、何も変更する必要はありません。それ以外の場合、obsetenv.bat(UNIXの場合はobsetenv.sh)を編集して、次の行を追加します。

    –Djavax.net.ssl.keyStore=path_to_your_certificate_store
     -Djavax.net.ssl.keyStorePassword=your_keystore_password
    

    注意:

    startorabpel.batファイル(UNIXの場合はstartorabpel.shファイル)を編集して、この行を追加することもできますが、使用しているオペレーティング・システムのobsetenv.*ファイルの編集をお薦めします。

  3. デフォルトとは異なるトラストストアファイルを使用している場合は、次のように入力してください。

    -Djavax.net.ssl.trustStore=path_to_truststore
    -Djavax.net.ssl.trustStorePassword=your_truststore_password
    

    関連項目:

    keytoolの使用の詳細は、http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#securityを参照してください。

1.3.1.2.2 パートナ・リンク・サーバーとOracle BPEL Serverクライアント証明書認証を使用したHTTP/S

この項では、Oracle BPEL Serverクライアントの構成方法について説明します。クライアント認証を必要とするパートナ・リンクを呼び出すクライアントの構成手順は、サーバー側認証のみを有効にしてパートナ・リンクを呼び出す手順と似ています。ただし、この環境でBPELにより使用されるキーストアは、次の場所に、次の証明書を格納しています。

  • それ自身の証明書(つまり、キーストアにおけるホストOC4Jサーバー証明書)

  • キーストアとトラストストアにおける、クライアント証明書、または双方が信頼している認証局証明書

大まかな手順は次のとおりです。

  1. 「ステップ1: OC4Jの構成」の説明に従って、SSLを使用してOC4Jを設定します。

  2. キーストアとトラストストアに、双方が信頼している認証局証明書が格納されていることを確認します。

  3. 「パートナ・リンク・サーバー証明書認証のみを使用したHTTP/S」の手順2で説明されている手順に従って、OC4JとBPELで正しいキーストアおよびトラストストアが使用されていることを確認します。

1.3.2 WS-Securityに準拠したサービス

パートナ・リンクでWS-Security準拠の認証トークンが必要な場合、トークンを使用してパートナ・リンクを呼び出すようにBPELを構成できます。 (図1-3を参照。)表1-3は、関連するプロパティを説明したものです。これらのプロパティは、個々のパートナ・リンク・レベルで構成できます。

表1-3 プロパティ

プロパティ名 説明 変更した場合
wsseHeaders 次の値を持つWS-Security UsernameTokenを作成します。
  • propagate

    プロセスが安全に呼び出された場合、アウトバウンド方向にもこれらの資格証明が使用されます。

  • credentials

    ディスクリプタから資格証明を渡します。

即座に有効になります。
wsseUsername トークンのユーザー名(必須) 即座に有効になります。
wssePassword トークンのパスワード(オプション) 即座に有効になります。


関連項目:

  • これらのデプロイメント・ディスクリプタ・プロパティの詳細は、『Oracle BPEL Process Manager開発者ガイド』を参照してください。

  • Web Services Security(WS-Security)仕様については、次のURLを参照してください。

    http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
    

1.3.2.1 SOAPバインディング

SOAPバインディングを使用するケースには次の4通りがあります。

  • ケース1

    WS-Securityヘッダーのために、パートナ・リンク経由で資格証明を伝播(プロセスが任意のAPIを経由して安全に呼び出されている場合)

  • ケース2

    Basic認証のために、パートナ・リンク経由で資格証明を伝播(プロセスが任意のAPIを経由して安全に呼び出されている場合)

  • ケース3

    WS-Security準拠のユーザー名トークンに格納され送信されるユーザー名およびパスワードを、静的に定義

  • ケース4

    HTTP Basic認証で使用され送信されるユーザー名およびパスワードを、静的に定義

1.3.2.1.1 構成

プロセスが安全に呼び出されている場合でも、デフォルトではOracle BPEL Serverは資格証明を伝播しません。BPELプロセス内で使用されているパートナ・リンクはすべて、BPELスーツケース内のbpel.xmlで定義されています。

<partnerLinkBindings>
  <partnerLinkBinding name="client">
    <property name="wsdlLocation">CreditRatingService.wsdl</property>
  </partnerLinkBinding>
</partnerLinkBindings>

ケース1の場合、次のプロパティを追加します。これにより、BPELでは送信コールにprocess-credentialsが追加されます。

<property name="wsseHeaders">propagate</property>

ケース2の場合、次のプロパティを追加します。これは、SOAPコール(setUsername, setPassword)に追加されます。

<property name="basicHeaders">propagate</property>

ケース3の場合、次のプロパティを追加します。これは、WS-Securityヘッダーを構築します。

<property name="wsseHeaders">credentials</property>
<property name="wsseUsername">your_user</property>
<property name="wssePassword">your_password</property>

ケース4の場合、次のプロパティを追加します。これは、SOAPコール(setUsername, setPassword)に追加されます。

<property name="basicHeaders">credentials</property>
<property name="basicUsername">your_user</property>
<property name="basicPassword">your_password</property>

注意:

これらすべてのプロパティは個々のパートナ・リンクをベースにしているため、該当するバインディングで指定されていないかぎり、他のパートナ・リンクに影響を与えることはありません。

2004年のWS-Security標準の変更後は、新しいネームスペースを適用する必要があります。適用しない場合、デフォルトのhttp://schemas.xmlsoap.org/ws/2002/07/secextネームスペースが使用されます。新しいネームスペースを適用するには、次のプロパティを追加します。

<property name="wsseOASIS2004Compliant">true</property>

1.3.3 カスタム認証ハンドラを持つAxisサービス

表1-4は、Axisサービスのパートナ・リンク・レベルで構成可能なプロパティを示したものです。

表1-4 プロパティ

プロパティ名 説明 変更した場合
basicHeaders 次の値を持つWS-Security UsernameTokenを作成します。
  • propagate

    プロセスが安全に呼び出された場合、アウトバウンド方向にもこれらの資格証明が使用されます。

  • credentials

    ディスクリプタから資格証明を渡します。

即座に有効になります。
basicUsername トークンのユーザー名(必須) 即座に有効になります。
basicPassword トークンのパスワード(オプション) 即座に有効になります。

1.3.4 J2EEのBasic認証で保護されたサービス(HTTP)

この項ではHTTP Basic認証について説明します。

この項で説明する内容は次のとおりです。

1.3.4.1 HTTP Basic認証(10.1.2.0.2)

表1-5は、パートナ・リンク・レベルで構成可能なデプロイ・ディスクリプタ・プロパティの一覧です。これらのプロパティは、10.1.2.0.2での認証にHTTPヘッダーを使用する認証サービスに対して設定できます。

表1-5 プロパティ

プロパティ名 説明 変更した場合
httpUsername HTTPユーザー名およびパスワードの認証に使用されます。 即座に有効になります。
httpPassword HTTPユーザー名およびパスワードの認証に使用されます。 即座に有効になります。

1.3.4.2 HTTPバインディング(10.1.3)

Oracle BPEL Process Managerリリース10.1.3以降、すべてのパートナ・リンク・プロパティは、HTTPヘッダーに自動的に伝播されるようになっています。しかし、アウトバウンドHTTPバインディングを使用した場合、資格証明が構成されていれば、これをBasic認証に使用できます。

<property name="httpBasicHeaders">credentials</property>

<property name="httpBasicUsername">your_username</property>
<property name="httpBasicPassword">your_password</property>

また、これらはプロセス・インスタンスから単に伝播することができます。

<property name="httpBasicHeaders">propagate</property>

1.3.5 JavaおよびEJBバインディング(10.1.3)

Oracle BPEL Process Managerリリース10.1.3以降、次のインタフェースを実装することにより、パートナ・リンク・プロパティを実装クラスまたはEJBに伝播できます。

com.oracle.bpel.client.wsif.IjavaEjbPlnkBindingInfo

これには次のメソッドが含まれます。

/**
 * This method will be called immediately after the new instance
 * of the class/bean has been created
 *
 * @param pProperties the map containing name/value pairs
 */
public void setPlnkProperties(HashMap pProperties);

このメソッドはクラス、またはBeanの作成直後にコールされます。また、このマップには、パートナ・リンク・プロパティがすべて含まれます。

1.4 Oracle BPEL ControlおよびOracle BPEL Admin Consoleのユーザーとロール

Oracle Application Serverの管理者アカウントoc4jadminでは、Oracle BPEL ControlおよびOracle BPEL Admin Consoleにログインし、BPELプロセスを管理できます。 このリリース以降、どちらのコンソールもOracle Application Server J2EEおよびJAASセキュリティ機能に完全に統合されています。

さらに、Oracle BPEL Process Managerには、Oracle BPEL ControlおよびOracle BPEL Admin ConsoleからBPELプロセスの管理を実行するためのユーザー、ロールおよびドメインのセットが自動的に含まれます。表1-6で、これらの機能について説明します。

表1-6 Oracle BPEL Process Managerのロール、ユーザーおよびドメイン

ユーザー ロール ドメイン
  • bpeladmin

    BPMSystemAdminロールおよびデフォルト・パスワードwelcome1を含むユーザー・アカウント。

  • BPMSystemAdmin

    Oracle BPEL ControlおよびOracle BPEL Admin Consoleからアクセスできるすべてのドメインにアクセス可能。

default — パーティション化およびプロセスのインスタンスの管理が可能。 必要に応じて追加ドメインを作成できる。
  • default

    BPMDefaultDomainAdminロールおよびデフォルト・パスワードwelcome1を含むユーザー・アカウント。

  • BPMDefaultDomainAdmin

    Oracle BPEL Controlからアクセスできるデフォルト・ドメインにのみアクセス可能。 このロールでは、Oracle BPEL Admin Consoleにはアクセスできません。



Oracle Application Serverの管理者アカウントoc4jadminにも、BPMSystemAdminロールが含まれます。

oc4jadminbpeladminおよびdefaultユーザーのパスワードは、Oracle Enterprise Manager 10g Application Server Control Consoleで変更できます。インストール後にbpeladminおよびdefaultユーザーのパスワードを変更することをお薦めします。

Oracle JDeveloperの「接続ナビゲータ」でアプリケーション・サーバー接続を作成する場合は、oc4jadminユーザー・アカウントを使用します。 その他のユーザー・アカウント、たとえばbpeladmindefault、または自分で作成した新規ユーザー・アカウントなどにはRMI権限がなく、Oracle JDeveloperでアプリケーション・サーバー接続を作成する際には使用できません。

新規ユーザーおよびグループを作成し、新規ドメインまたはOracle BPEL Process Managerに自動的に含まれているデフォルト・ドメインに割り当てることができます。

この項では、次の例を示します。


注意:

これらの例では、a:/home/oc4j/bpel/liborabpel-boot.jarのディレクトリの場所として使用しています。このパスを、使用している環境に適したパスに置き換えてください。


関連項目:

  • BPMSystemAdminロールおよびBPMDefaultDomainAdminロールの詳細は、付録A「デモ・ユーザー・コミュニティ」を参照してください。

  • BPMSystemAdminロールおよびBPMDefaultDomainAdminロールとドメイン管理の詳細は、『Oracle BPEL Process Manager開発者ガイド』を参照してください。

  • oc4jadminbpeladminおよびdefaultパスワードの変更手順は、『Oracle Application Server管理者ガイド』を参照してください。

  • Java SSO(JSSO)、OracleAS JAAS Provider Admintoolの例、およびファイルベース・プロバイダとOracle ID管理プロバイダに使用できる追加セキュリティ管理ツールの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。


1.4.1 例1: 新規BPELドメインにアクセスするための新規ユーザーおよびグループの作成

この項では、新規BPELドメインにアクセスするための新規ユーザーおよびグループの作成方法を説明します。 この例では、Oracle Internet Directoryを使用してユーザーおよびグループを作成し、XMLベースのJAZNプロバイダのOracleAS JAAS Provider Admintoolを使用して新規ユーザーおよびグループに必要なドメイン権限を付与します。 ユーザーおよびグループの作成に使用する管理ツールは、使用しているIDサービス・プロバイダのタイプによって決まります。

  1. 「10.1.2 Oracle Internet Directoryを使用したIdentity Service 10.1.3.1.0の構成」の説明に従い、10.1.2 Oracle Internet Directoryを使用して10.1.3.1.0 Identity Serviceを構成します。

  2. Oracle BPEL Admin ConsoleでsoaAdminという新規ドメインを作成します。

  3. Oracle Internet Directoryで、soaAdminという新規ユーザーおよびBPMsoaAdminDomainAdminというグループを作成します。

  4. JAZN管理ツールを使用して、ユーザーsoaAdminまたはグループBPMsoaAdminDomainAdminにドメイン権限を付与します。

    java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
    -shell -grantperm jazn.com -user soaAdmin com.collaxa.security.DomainPermission
    soaAdmin all
    
    

    または

    java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
    -shell -grantperm jazn.com -role BPMsoaAdminDomainAdmin
    com.collaxa.security.DomainPermission soaAdmin all
    
    

    内容

    • com.collaxa.security.DomainPermission — 権限クラス名です。この権限クラスでは、Oracle BPEL Admin Consoleにはアクセスできません。

    • soaAdmin — 権限クラスに対するパラメータです。 このパラメータは、ユーザーがアクセスできるドメインの名前を示します。

    • all — 権限クラスに対するパラメータです。 このパラメータは、ユーザーまたはグループが実行できるアクションのレベルを示します。


    注意:

    ユーザーsoaAdminまたはグループBPMsoaAdminDomainAdminは、soaAdminドメイン内のすべての権限を受け取るか、またはどの権限も受け取りません。 読取り専用権限、更新権限などの指定といった特定のアクションをユーザーまたはグループに割り当てることはできません。

  5. Oracle BPEL Controlにログインします。

1.4.2 例2: デフォルトBPELドメインにアクセスするための新規ユーザーの作成

この項では、Oracle BPEL Process Managerに自動的に含まれているデフォルトBPELドメインにアクセスするための新規ユーザーの作成方法を説明します。 この例では、OracleAS JAAS Provider Admintoolを使用してユーザーを作成し、BPMDefaultDomainAdminロールをユーザーに付与します。 ユーザーの作成に使用する管理ツールは、使用しているIDサービス・プロバイダのタイプによって決まります。

  1. レルムjazn.comに、パスワードwelcomemikeというユーザーを作成します。

    % java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
     -shell -adduser jazn.com mike welcome
    
    
  2. レルムjazn.comで、ロールBPMDefaultDomainAdminをユーザーmikeに付与します。

    % java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
     -shell -grantrole BPMDefaultDomainAdmin jazn.com mike
    
    
  3. Oracle BPEL Controlにログインします。

1.4.3 例3: すべてのBPELドメインにアクセスするための新規ユーザーの作成

この項では、すべてのBPELドメインにアクセスするための新規ユーザーの作成方法を説明します。 この例では、OracleAS JAAS Provider Admintoolを使用してユーザーを作成し、BPMSystemAdminロールをユーザーに付与します。 ユーザーの作成に使用する管理ツールは、使用しているIDサービス・プロバイダのタイプによって決まります。 このユーザーは、com.collaxa.security.ServerPermission権限も受け取ります。 この権限では、すべてのドメインおよびOracle BPEL Admin Consoleにアクセスできます。 この権限には、default(com.collaxa.security.DomainPermission)権限も自動的に含まれます。

  1. レルムjazn.comに、パスワードwelcomemikeというユーザーを作成します。

    % java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
     -shell -adduser jazn.com mike welcome
    
    
  2. レルムjazn.comで、ロールBPMSystemAdminをユーザーmikeに付与します。

    % java -Xbootclasspath/a:/home/oc4j/bpel/lib/orabpel-boot.jar -jar jazn.jar
     -shell -grantrole BPMSystemAdmin jazn.com mike
    
    
  3. Oracle BPEL Controlにログインします。

1.5 デフォルト・バリデータとカスタム・バリデータ

ユーザーを認証するためのIDストア・バリデータには、次の2種類があります。

1.5.1 デフォルト・バリデータの使用

Oracle BPEL Process Managerでは、BPEL Identity Serviceを通じて、IDストアへのブリッジが提供されます。たとえば、Oracle Application Serverでは、JAZN、Oracle Internet Directory(OID)またはカスタム・リポジトリ・プラグインをIDストアとして使用できます。

あるユーザーがBPELプロセスを呼び出す場合、構成済ストアにこのユーザーの名前が格納されている必要があります。JAZNの場合は、SOA_Oracle_Home¥j2ee¥home¥config¥system-jazn-data.xml(Oracle BPEL Process Manager for OracleAS Middle Tierインストール・タイプの場合)に作成されている必要があります。次に例を示します。

<user>
   <name>Clemens</name>
   <credentials>!yourpassword</credentials>
</user>

BPELセキュリティの検証は、次の順序で評価されます。

  • BPELスーツケースにbpel.xmlconfigurationsタグ内の資格証明が含まれるかどうか。次に例を示します。

    <property name="user">Clemens</property>
    <property name="pw">your_password</property>
    
    
  • BPELスーツケースでロールが指定されている場合は、リクエストで指定されたユーザーはID管理ストアに存在し、そのグループに属している必要があります。

    <property name="role">administrators</property>
    
    

    多数のプロセスが使用されており、各プロセスに対する新しいロールでID管理を再構成できない場合に、この方法が便利です。

  • 前述のセキュリティ・バリデータがどちらも見つからない場合、BPELではプロセス名とExecutionRoleが結合されます。また、指定されたユーザーは、この名前のロールに属している必要があります。たとえば、ユーザーClemensCreditRatingServiceプロセスを呼び出した場合、このユーザーはIDストア(たとえば、JAZNを使用している場合はsystem-jazn-data.xml)で定義されているグループCreditRatingServiceExecutionRoleに属している必要があります。

    <role>
       <name>CreditRatingServiceExecutionRole</name>
          <members>
             <member>
                <type>user</type>
                <name>Clemens</name>
             </member>
           </members>
    </role>
    

関連項目:

  • 「IDサービスの構成」

  • BPELのIDサービスの詳細は、『Oracle BPEL Process Manager開発者ガイド』を参照してください。


1.5.2 カスタム・バリデータの作成

デフォルトのバリデータでは要件が満たされない場合、カスタム・バリデータの実装が必要になる場合もあります。このためには、次のインタフェースを実装し、メッセージ・ハンドラを構成する必要があります。

/**
 * This source is proprietary to ORACLE CORPORATION
 * 2005, All rights reserved
 */
package com.oracle.bpel.security;

import com.oracle.bpel.client.ServerException;

import com.oracle.bpel.client.NormalizedMessage;
import com.oracle.bpel.client.BPELProcessId;

/**
 * Public abstract class that has to be implemented
 * for having a valid ACLManager that is used by the BPEL server
 * for authentication & authorization
 *
 * @version 1.1
 */
public abstract class ACLManager extends BaseACLManager {

  /**
   * Public constructor that should use a cache for connections
   * and care about other stuff.
   * @throws com.oracle.bpel.client.ServerException
   * @since 1.0
   */
  public ACLManager() throws ServerException
  {
  }

  /**
   * Checks if a user is valid in the context of a secured Process
   *
   * @return valid or not
   * @param pMessage the message will hold all information, including
   * the domain information and headers
   * @throws ServerException in case something breaks
   */
  public abstract boolean validateUser
     (BPELProcessId pProcessID, NormalizedMessage pMessage) throws
        ServerException;

  /**
   * Checks if a user is allowed to execute (=invoke) a certain revision
   * (if given) of a process.
   *
   * @return true if he is otherwise false
   * @param pProcessId the name, domain and revision of the process
   * @param pMessage the message will hold all information, including
   * the domain information and headers
   * @throws ServerException in case something breaks
   */
  public abstract boolean isAllowedToExecuteProcess
   (BPELProcessId pProcessID, NormalizedMessage pMessage)
      throws ServerException;

  /**
   * Checks if a user is allowed to execute (=invoke) a certain activity
   * of a process.
   *
   * @return true if he is otherwise false
   * @param pProcessId the name, domain and revision of the process
   * @param pActivityName the name of the Activity
   * @param pMessage the message will hold all information, including
   * the domain information and headers
   * @throws ServerException in case something breaks
   */
  public abstract boolean isAllowedToExecuteActivity
     (BPELProcessId pProcessID, NormalizedMessage pMessage, String  pActivityName)
         throws ServerException;

  /**
   * Checks if a user is allowed to lookup  a certain revision
   * (if given) of a process.
   *
   * @return true if he is otherwise false
   * @param pMessage the message will hold all information, including
   * the domain information and headers
   * @param pProcessId the name, domain and revision of the process
   * @throws ServerException in case something breaks
   */
  public abstract boolean isAllowedToLookupProcess
     (BPELProcessId pProcessID, NormalizedMessage pMessage)
         throws ServerException;

  /**
   * Checks if a user is allowed to lookup a certain activity of a process.
   *
   * @return true if he is otherwise false
   * @param pActivityName the name of the Activity
   * @param pProcessId the name, domain and revision of the process
   * @throws ServerException in case something breaks
   */
  public abstract boolean isAllowedToLookupActivity
     (BPELProcessId pProcessID, NormalizedMessage pMessage, String  pActivityName)
         throws ServerException;

}

実装後、クラス・ローダーがアクセスできるようにするには、このクラスをSOA_Oracle_Home¥bpel¥system¥classesに格納する必要があります。2番目のステップでは、message-handlers.xmlで次のプロパティを構成します。

<property id="ACLManager">
<value>com.oracle.bpel.security.validator.bpmid.BPMIdentityValidator</value>
   <comment>BPMIdentityValidator uses the server configured security such
      as JAAS to validate the user against
   </comment>
</property>

ここで、valueは実装したバリデータ・クラスのクラス名(パッケージを含む)をポイントする必要があります。

1.6 プロキシ・サーバーによるパートナWebサービスの呼出し

Oracle BPEL Process Managerを構成し、プロキシ・サーバーを使用してパートナWebサービスを呼び出すことができます。

たとえば、Oracle BPEL Process Managerがホストinternal123.company.comにインストールされており、デプロイされたBPELプロセスのいずれか1つが、ファイアウォールの外側のhttp://services.myPartner.comでホストされている同期Webサービスを呼び出す必要があるとします。 アウトバウンドHTTPトラフィックはすべて、ポート8090myproxy004.company.comにあるHTTPプロキシ・サーバーを介してルーティングされる必要があります。

HTTPプロキシ・サーバーによりパートナWebサービスを呼び出すようantタスクおよびOracle BPEL Process Managerを構成するには、次の手順を実行します。

  1. WindowsではSOA_Oracle_Home\bpel\bin\obsetenv.batファイルを開き、UnixまたはLinuxではSOA_Oracle_Home/bpel/bin/obsetenv.shファイルを開きます。

  2. set OB_JAVA_PROPERTIES=の行を次のように変更します。

    set OB_JAVA_PROPERTIES="-Dhttp.proxySet=true"
    "-Dhttp.proxyHost=myproxy004.company.com"
    "-Dhttp.proxyPort=8090" "-Dhttp.nonProxyHosts=internal123.company.com"
    
    

    http.proxySettrueに設定することで、クライアント・プロキシをアクティブにし、アウトバウンド・トラフィックをすべてhttp.proxyHostおよびhttp.proxyPortを介してリダイレクトします。 http.nonProxyHostsを、Oracle BPEL Serverをホストするサーバーに設定し、ローカル・リクエストがプロキシを通過するのを防ぎます。 |をデリミタとして使用することで、nonProxyHostsリストを拡張して企業ネットワーク内のその他のサーバーを含めたり、internal123ホストに対するその他の論理名を含めることができます。

1.7 認可、メッセージの暗号化および電子署名のためのOracle Web Services Managerの使用

Oracle BPEL Process Managerでは、現在のところ、サポートされていないセキュリティ機能がいくつかあります。このような機能については、Oracle Web Services Managerを使用できます。Oracle Web Services Managerでは、高度な認証機能が提供されます。Oracle Web Services Managerでは、HTTP Basic認証、COREid、Netegrity、LDAP、X.509証明書およびWS-Securityを使用した認証がサポートされています。

この項で説明する内容は次のとおりです。


関連項目:

  • 『Oracle Web Services Manager インストレーション・ガイド』

  • 『Oracle Web Services Manager デプロイメント・ガイド』

  • 『Oracle Web Services Manager管理者ガイド』

  • 『Oracle Web Services Manager アップグレード・ガイド』

  • 『Oracle Web Services Manager 拡張ガイド』


1.7.1 認可

BPELによるサービスの呼出しに関連するアウトバウンド認証には、サービス・プロバイダおよびサービス・プロバイダによる認可の実装が必要です。現在のところ、Oracle BPEL Process Managerでは、インバウンド認証はサポートされていませんが、認証されたユーザーがBPELプロセスにアクセスできるようにするために、Oracle Web Services Managerにより、次の機能が提供されます。

  • XMLメッセージのいずれかの部分、または本文に含まれる情報に基づく認可のサポート

  • 次に示すきめ細かいアクセス制御の提供

    • サービス・レベルでのアクセス制御

    • SOAPメソッド・レベルでのアクセス制御

  • WS-Securityのサポート

1.7.2 メッセージの暗号化と復号

この項では、実際のメッセージの暗号化について説明します。XML暗号化はWS-Securityプロファイルでカバーされています。現在のところ、Oracle BPEL Process Managerでは、XML暗号化はサポートされていませんが、Oracle Web Services Managerにより次の暗号化機能や復号機能が提供されます。

  • WS-Securityに準拠したメッセージおよびコンテンツの暗号化と復号。

  • メッセージ全体または一部の暗号化。これにより、暗号化を必要とするメッセージの部分にXPath式を指定できます。

1.7.3 電子署名

現在のところ、Oracle BPEL Process Managerでは電子署名はサポートされていませんが、Oracle Web Services Managerにより、電子署名や署名検証機能が提供されます。クライアントでサービスが呼び出されると、Oracle Web Services Managerでは次のタスクが実行されます。

  • このリクエストがインターセプトされます。

  • このサービスに、守る必要のある電子署名検証ポリシーが存在しているかどうかの確認が行われます。

  • 署名が検証されます。

  • サービスが提供されるよう、このリクエストがBPELに渡されます。

同様に、BPELによりパートナ・リンクが呼び出された場合、Oracle Web Services ManagerではメッセージのSOAPヘッダーに電子署名が添付されます。

1.8 まとめ

この章では、次の手順を実行する方法について説明しています。

また、この章では、Oracle BPEL Process Managerで使用できるデフォルト、およびカスタムのIDストア・プロバイダについても説明しています。さらに、Oracle Web Service Managerの概要についても説明しています。Oracle Web Service Managerは、Oracle BPEL Process Managerに認可、メッセージの暗号化と復号、および電子署名のサポートを提供するために使用できます。