| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1) E69914-01 |
|
 前 |
 次 |
この章では、Service Busのカスタム・トランスポート・レベルおよびメッセージ・レベルの認証を構成する方法について説明します。
この章の内容は次のとおりです。
プロキシまたはビジネス・サービス・セキュリティを構成する手順については、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。
Service Busは、トランスポート・レベルのプロキシおよびビジネス・サービス・リクエストと、メッセージ・レベルのプロキシ・サービス・リクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証資格証明は、トークン、またはユーザー名とパスワードのトークンの組合せになります。トランスポート・レベルでは、HTTPヘッダーでプロキシまたはビジネス・サービスに渡されるカスタム・トークンを受け入れて、認証を試行します。メッセージ・レベルでは、SOAPヘッダー(SOAPベース・サービスの場合)またはペイロード(非SOAPサービスの場合)から情報を取得できます。
プロキシ・サービス定義エディタを使用して、トークン・タイプとトークンが渡されるメカニズムによりプロキシ・サービスを構成します。ビジネス・サービスについては、カスタム認証Javaクラスを定義して、それをビジネス・サービス定義エディタから参照できます。
注意:
カスタム認証のメカニズムは、単独かWebサービスのメッセージ・レベルのセキュリティとともに機能します。これについては、「Webサービスのメッセージ・レベルでのセキュリティの構成」で説明しています。両方のタイプのセキュリティの使用について詳しくは、「WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ」を参照してください。
認証トークンは、文字列やXMLで表される何らかのデータで、X509クライアント証明書などのエンティティ(ユーザーまたはプロセス)を識別します。認証トークンは通常、特定のセキュリティ・プロトコル内で使用されることを意図しています。暗号により保護されている認証トークンもあれば、そうでないものもあります。一部の認証トークンは、重要なキー・マテリアルを持っています。
Service Busの文脈では、カスタム認証トークンはユーザー名およびパスワードであったり、リクエスト内のユーザー定義の場所にある不透明なIDアサーション・トークンであることもあります。ユーザー名およびパスワードのトークンは、SOAPヘッダー(SOAPベースのサービスの場合)または非SOAPプロキシ・サービスのペイロードで使用されます。IDアサーション・トークンは、HTTPヘッダーやSOAPヘッダー(SOAPベースのサービスの場合)、または非SOAPプロキシ・サービスのペイロード内で使用可能です。Service Busドメインには、トークン・タイプをサポートするIDアサーション・プロバイダを含める必要があります。
Service Busは、認証されたユーザーを使用して、クライアントのセキュリティ・コンテキストを確立します。カスタム・トークンやユーザー名およびパスワードを認証することで確立されたセキュリティ・コンテキストは、アウトバウンド資格証明のマッピングおよびアクセス制御の基礎として使用できます。認証のためにトークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をService BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。
Service Busでのカスタム認証トークンのサポートにより、2つの要件に対応します。1番目の要件は、プロキシ・サービスのリクエストのメッセージ・ペイロードのどこか(SOAPヘッダーなど)にユーザー名およびパスワードがある場合です。Service Busは、このユーザー名およびパスワードを取得して、ユーザーを認証する必要があります。2番目の要件は、メッセージにsecure-token-xyzトークンなど何らかの認証トークン(ユーザー名およびパスワード以外)が含まれている場合です。トークンは、HTTPヘッダーまたはメッセージのペイロード内にある場合があります。Service Busは、このトークンを取得して認証する必要があります。どちらの場合でも、認証に成功するとセキュリティ・コンテキストが確立されます。
一般に、ほとんどのセキュリティ関連の構成はデプロイメント時に実行され、カスタム認証はそのモデルに適合します。これは、デプロイメント時に本番環境で直接構成できます。または、ステージングの際に認証を構成して、それを本番環境にインポートすることもできます。
カスタム認証(カスタム・トークンと、ユーザー名およびパスワードのトークンを含む)は、プロキシ・サービスの定義の中核です。プロキシ・サービスがエクスポートされるとき、カスタム・トークンのすべての構成がJARファイルに含まれます。新しいバージョンのプロキシ・サービスがインポートされる場合、前の構成はこのJARファイルに含まれる構成にオーバーライドされます。
カスタム・トークン認証を構成できるのは、Middleware管理者または開発者のアプリケーション・ロール(あるいは統合デプロイヤまたは統合管理者のエンタープライズ・ロール)のユーザーのみです。ロールの詳細については、「Oracle Service Busの管理」のOracle Service Busでのロール・ベースのアクセスに関する項を参照してください。
HTTPヘッダーで指定できるカスタム認証トークンを使用して、トランスポート・レベルでクライアントのリクエストを認証できます。トランスポート・レベルのカスタム認証は、サービス定義エディタの「トランスポートの詳細」ページで構成します。HTTPサービスおよびHTTPSサービスのオプションは次のとおりです。
なし
基本
カスタム認証
クライアント証明書(HTTPSのみ)
これらのオプションは同時に複数選択することはできません。
プロキシ・サービスのカスタム認証を選択する場合は、トークン・タイプと、そのトークンを運ぶHTTPヘッダーの名前も指定する必要があります。ビジネス・サービスのカスタム認証を選択する場合は、カスタム・オーセンティケータのJavaクラスも指定する必要があります。カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。
トランスポート・レベルのカスタム認証トークンは、UDDIにパブリッシュされます。client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。「トランスポート属性」で説明されているとおり、client-authに指定可能な値はBASIC、CLIENT-CERTおよびCUSTOM-TOKENです。値がCUSTOM-TOKENの場合は、さらにtoken-headerとtoken-typeという2つのプロパティが必ず存在します。
Service Busは、プロキシ・サービスのメッセージ・レベルのリクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。Service Busは、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークンを受け入れて、認証しようとします。「セキュリティ」ページ(Oracle Service Busコンソール)またはプロキシ・サービス定義エディタの「セキュリティ設定」ページ(JDeveloper)で、トークン・タイプおよびトークンを渡すメカニズムの指定を含めて、メッセージ・レベルのカスタム認証を構成します。
サポートされているプロキシ・サービスのメッセージ・レベルの認証メカニズムは次のとおりです。
SOAPベースのプロキシ・サービスの場合
SOAPヘッダーのカスタム・トークン
SOAPヘッダーのユーザー名/パスワード
非SOAPベースのプロキシ・サービスの場合
任意のXMLベースのプロキシ・サービスのペイロードに含まれるカスタム・トークン
任意のXMLベースのプロキシ・サービスのペイロードに含まれるユーザー名/パスワード
メッセージ・レベルのカスタム・トークン、およびメッセージ・レベルのユーザー名とパスワードが以下のバインディング・タイプのプロキシ・サービスでサポートされます。
WSDL-SOAP
WSDL-XML
抽象SOAP
抽象XML
混合 - XML(リクエスト内)
混合 - MFL(リクエスト内)
カスタムのトークンまたはカスタムのユーザー名/パスワードにより確立されるセキュリティ・コンテキストは、決して一意ではなく、それを資格証明のマッピングに使用できます。トランスポート・レベルの認証とメッセージ・レベルの認証を両方とも実装する場合、メッセージ・レベルのセキュリティ・コンテキストは、常に資格証明のマッピングとIDの伝播に使用されます。
たとえば、プロキシ・サービスがSOAPヘッダーのsecure-token-xyzトークンによってクライアントを認証する場合、マップされたすべてのサービス・アカウントのルックアップ中に、認証されたサブジェクトが使用されます。サブジェクトはアウトバウンド・メッセージ上でSAMLトークンが生成されるときにも使用されます。また、カスタム・トークンまたはカスタムのユーザー名/パスワードに関連する認証コンテキストの下で、Javaコールアウトが実行可能です。
カスタムのユーザー名/パスワードを使用する場合、パススルー・サービス・アカウントが使用されるときは、カスタム・トークン内のユーザー名/パスワードをアウトバウンドHTTP BasicまたはアウトバウンドWS-Securityユーザー名トークンの認証に使用できます。
トランスポート・レベル・セキュリティ(たとえば、HTTPS)またはメッセージ・レベル・セキュリティ(たとえば、WS-Security (WSS)とカスタム・トークン)、あるいはその両方の組合せによってService Busプロキシ・サービスを保護できます。たとえば、クライアントのリクエストをHTTPヘッダーのカスタム・トークンを使用してトランスポート・レベルで認証したり、WS-Securityヘッダーを除く、WS-Securityトークンやカスタム・トークン、ユーザー名/パスワードを使用して、メッセージ・レベルで認証したりできます。
制限が1つあります。WS-Securityとメッセージ・レベルのカスタム・トークンを組み合せることは可能ですが、WS-SecurityポリシーはWS-Securityトークンに基づいてプロキシ・サービス認証を要求することはできません 。メッセージ・レベルのカスタム・トークンとWS-Securityプロキシ・サービス認証は、同時に両方を選択することはできません。
次の例を参考にしてください。
SOAPヘッダー<soap:MyToken>にタイプがMyTokenのカスタム・トークンを想定し、何らかのメッセージ部分(<soap:MyToken>ヘッダーおよびSOAP本体など)の署名や暗号化を要求するWS-Securityポリシーを持つプロキシ・サービスを構成することはできません。
ヘッダー<soap:MyToken>にカスタム・トークンを要求し、SAMLトークンや他の形式の認証を要求するWS-Securityポリシーも持っているプロキシ・サービスを構成することはできません。
カスタム・ユーザー名/パスワードを使用する認証と、カスタム・トークンを使用する認証の構成はほぼ同じです。どちらの場合も、Service Busで必要な情報を検索できるようにするためのXPath式を指定します。これらのXPath式のルートは次のとおりです。
サービスのバインドがanySOAPまたはWSDL-SOAPの場合は、soap-env:Envelope/soap-env:Headerを使用します。
サービスのバインドがSOAPベースでない場合は、soap-env:Body(具体的には、$body変数の内容)を使用します。
注意:
すべてのXPath式は有効なXPath 2.0形式である必要があります。使用するネームスペースをXPath式で宣言するには、次のようなXPathの"declare namespace"構文を使用します。
declare namespace ns='http://webservices.mycompany.com/MyExampleService';
次に例を示します。
declare namespace y="http://foo";./y:my-custom-token/text()
IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する特殊な形態の認証プロバイダです。クライアントのIDは、クライアントから提供されるトークンを使用することにより確立されます。IDアサーション・プロバイダは、トークンを検証します。トークンが正常に検証されると、IDアサーション・プロバイダは、トークンをService Busユーザー名にマップしてそのユーザー名を返します。トークンがユーザー名にマップされることを、IDが「アサートされた」といいます。Service Busは、このユーザー名を使用してクライアントのセキュリティ・コンテキストを確立します。
プロキシまたはビジネス・サービスでカスタム・トークンを消費するには、提供されたWebLogic ServerのIDアサーション・プロバイダをチェックして、ニーズに合うかを確認してください。WebLogic Serverには、次のような幅広いIDアサーション・プロバイダが含まれています。
WebLogic IDアサーション・プロバイダは、X.509およびIIOP-CSIv2トークンを検証します。必要に応じてユーザー名マッパーを使用し、そのトークンをユーザーにマップできます。
SAML IDアサーション・プロバイダは、SAMLセキュリティ・アサーションのコンシューマとして機能します。
このサービスで、secure-token-xyzトークンなど、バンドルされたIDアサーション・プロバイダにより処理されないカスタム・トークンを消費する場合、ユーザー(またはサードパーティ)は最初にトークン・タイプをサポートするWebLogic Server IDアサーション・プロバイダを記述し、Oracle WebLogic Server管理コンソールを使用して、そのプロバイダをセキュリティ・レルムに追加する必要があります。
IDアサーション・プロバイダを開発して、ユーザーのIDをアサートするときに使用する特定のタイプのカスタム・トークンをサポートします。複数のトークン・タイプをサポートするために、IDアサーション・プロバイダを開発することができます。1つのセキュリティ・レルムに、同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを持つことはできますが、この検証を実際に実行できるのは、1つのIDアサーション・プロバイダだけです。
図55-1に、カスタム認証用に構成されたプロキシ・サービスのIDアサーション・プロセスを示します。このプロセスは、次のように機能します。
詳細は、『Oracle WebLogic Serverセキュリティの理解』のIDアサーションおよびトークンに関する項を参照してください。
トランスポート・レベルのIDアサーションの場合、ヘッダーの値はjava.lang.StringとしてIDアサーション・プロバイダに渡されます。メッセージ・レベルのIDアサーションの場合は、XPath式が次のように評価されます。
XPath式が複数のノードを戻す場合、エラーが発生してIDアサーションは呼び出されません。
XPath式が空の結果を戻す場合、nullの引数を持つIDアサーションが呼び出されます。
XPath式がタイプTEXTまたはATTRの単一のトークンを戻す場合(http://xmlbeans.apache.org/docs/2.0.0/reference/org/apache/xmlbeans/XmlCursor.TokenType.htmlにあるXmlCursor.TokenTypeを参照)、テキスト・ノードの文字列の値または属性が渡されます(XmlCursor.getStringValue()によって戻される場合と同じように)。それ以外の場合は、単一のXmlObjectが渡されます。
これらのタスクを完了するために必要な手順は、次のWebLogic Serverのドキュメントで説明されています。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項では、IDアサーション・プロバイダ用のカスタムのトークン・タイプを作成する方法について説明しています。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』では、Oracle WebLogic Server管理コンソールでのIDアサーション・プロバイダの構成方法について説明しています。
参考までに、IDアサーション・プロバイダ用のカスタム・トークン・タイプを作成する手順と、そのプロバイダをOracle WebLogic Server管理コンソールで構成する手順について、ここで簡単にふれています。ただし、実際にこのタスクを完了するには、WebLogic Serverのドキュメントに目を通す必要があります。
IDアサーション・プロバイダでカスタム・トークン・タイプを構成するには:
SampleIdentityAsserterProviderImpl.javaクラスについて説明しています。これは、サンプルのIDアサーション・プロバイダのランタイム・クラスです。 カスタムのIDアサーション・プロバイダを構成するときは、「サポートされている種類」フィールドにIDアサーション・プロバイダがサポートしているトークン・タイプのリストが表示されます。「アクティブな種類」フィールドにゼロまたはそれ以上のサポートされているタイプを入力します。
「サポートされている種類」フィールドの内容は、カスタムIDアサーション・プロバイダのMBeanタイプを生成するために使用するMBean定義ファイル(MDF)のSupportedTypes属性から取得されます。サンプルIDアサーション・プロバイダの例を次の例で示します。MDFおよびMBeanタイプの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のWebLogic MBeanMakerによるMBeanタイプの生成に関する項を参照してください。
例 - SampleIdentityAsserter MDF : SupportedTypes属性
<MBeanType>
...
<MBeanAttribute
Name = "SupportedTypes"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {"SamplePerimeterAtnToken"}"
/>
...
</MBeanType>
同様に、「アクティブな種類」フィールドの内容は、MBean定義ファイル(MDF)のActiveTypes属性から取得されます。MDFファイルのActiveTypes属性をデフォルトに設定すると、Oracle WebLogic Server管理コンソールで手動設定する必要がなくなります。サンプルIDアサーション・プロバイダの例を次の例で示します。
例 - SampleIdentityAsserter MDF: Defaultを使用したActiveTypes属性
<MBeanAttribute
Name= "ActiveTypes"
Type= "java.lang.String[]"
Default = "new String[] { "SamplePerimeterAtnToken" }"
/>
ActiveTypes属性のデフォルト化は便利ですが、他のIDアサーション・プロバイダがそのトークン・タイプを検証することがない場合にのみ行うようにします。それ以外の場合、無効なセキュリティ・レルムが構成されることになるおそれがあります(複数のIDアサーション・プロバイダが同じトークン・タイプを検証しようとします)。一番良いのは、IDアサーション・プロバイダのすべてのMDFがデフォルトでそのトークン・タイプをオフにすることです。その場合、そのトークン・タイプを検証するIDアサーション・プロバイダを構成して手作業でアクティブにすることができます。
トランスポート・レベルのセキュリティ用にHTTPプロキシまたはビジネス・サービスを構成するには、使用するトークン・タイプを認識するIDアサーション・プロバイダを構成するか、作成して構成しておく必要があります。
アウトバウンドのカスタム認証では、カスタム・ロジックを定義するカスタムJavaクラスを作成する必要があります。次のインタフェースは、ビジネス・サービス用のカスタム認証を実装するために必要なメソッドを提供します。
com.bea.wli.sb.transports.http.OutboundAuthentication
com.bea.wli.sb.transports.http.HttpUrlConnectionFactory
カスタム・オーセンティケータは、OutboundAuthenticationインタフェースのdoOutboundAuthenticationメソッドを実装する必要があります。カスタム・オーセンティケータは、認証ヘッダーを設定して、初期トランザクションおよび中間トランザクションのターゲット・サービスからのレスポンスを読み取ることができます。最終ステップとして、カスタム・オーセンティケータは認証ヘッダーのみを設定し、ターゲット・サービスとの接続は確立しないことが想定されています。最終ステップでは、Service Busが認証ヘッダーとともにペイロードを送信します。カスタム・オーセンティケータではペイロードを操作しないでください。
次の手順は、トランスポート・レベルでカスタム認証を定義するために完了する必要があるステップの概要を示しています。より詳細な手順へのリンクが含まれます。
トランスポート・レベルのカスタム認証を構成するには:
使用するカスタム・トークンの形式を決定します。
既存のプロバイダがニーズに合うかどうかを判断します。詳細については、『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの選択に関する項を参照してください。
トークンの形式をサポートするIDアサーション・プロバイダを、構成あるいは作成してから構成してください。次の手順を参照してください。
既存のIDアサーション・プロバイダの構成については、Oracle WebLogic Serverのセキュリティの管理の認証プロバイダの構成に関する項(具体的には、IDアサーション・プロバイダの構成に関する項)を参照してください。
プロバイダのカスタム・トークン・タイプの作成については、「IDアサーション・プロバイダでのカスタム・トークン・タイプの構成方法」を参照してください。
カスタム・プロバイダの開発については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。
IDアサーション・プロバイダが、トークンをユーザー名にマップします。Fusion Middleware Controlでクライアントのユーザー名を追加します。
プロキシ・サービスについて、プロキシ・サービス定義エディタの「トランスポートの詳細」ページで次の手順を実行します。
認証で、「カスタム認証」を選択します。
「詳細オプション」(または「詳細設定」)の「認証ヘッダー」フィールドで、Service Busがトークンを検索できるメッセージ・ヘッダーを入力します。
「認証トークン・タイプ」で、このエンドポイントで想定されるトークン・タイプを入力します。
ビジネス・サービスでは、カスタム・オーセンティケータJavaクラスを作成およびコンパイルして、システム・クラスパスにクラスを追加します。
ビジネス・サービスについて、ビジネス・サービス定義エディタの「トランスポートの詳細」ページで次の手順を実行します。
認証で、「カスタム認証」を選択します。
「HTTPカスタム認証クラス名」フィールドで、カスタム認証を定義するJavaクラスの名前を入力します。
変更を保存してアクティブ化します。
