|
|
Oracle Service Bus は、転送レベルおよびメッセージレベルの両方のプロキシ サービス要求に対するクライアント指定のカスタム認証資格をサポートします。カスタム認証資格は、トークン、またはユーザ名とパスワードのトークンの組み合わせになります。
Oracle Service Bus は、HTTP ヘッダ、SOAP ヘッダ (SOAP ベースのプロキシ サービス)、またはペイロード (非 SOAP プロキシ サービスの場合) でプロキシ サービスに渡されるカスタム トークンを受け取り、認証しようとします。トークンが渡されるメカニズムおよびトークン タイプを使用してプロキシ サービスをコンフィグレーションするには、プロキシ サービスのコンフィグレーション ウィザードを使用します。
また、Oracle Service Bus では、SOAP ヘッダ (SOAP ベースのプロキシ サービスの場合) または非 SOAP プロキシ サービスのペイロードで渡されるユーザ名とパスワード トークンを受け取り、認証しようとします。ユーザ名とパスワードが渡されるメカニズムを使用してプロキシ サービスをコンフィグレーションするには、プロキシ サービスのコンフィグレーション ウィザードを使用します。
| 注意 : | カスタム認証メカニズムは、単独、または「Web サービスのメッセージレベルでのセキュリティのコンフィグレーション」に記載されている Web サービス用のメッセージレベルのセキュリティとの組み合わせて動作します。両方のセキュリティのタイプについては、「WS-Security およびカスタム ユーザ名/パスワードとトークンの組み合わせ」を参照してください。 |
認証トークンは文字列または XML で表されるデータで、X509 クライアント証明書などのエンティティ (ユーザまたはプロセス) を指定します。通常、認証トークンは、特定のセキュリティ プロトコル内で使用するように設計されています。認証トークンは暗号で保護されているものも、そうでないものもあります。一部の認証トークンには重要な情報が入っています。
Oracle Service Bus のコンテキストでは、カスタム認証トークンはユーザ名/パスワード、または要求のユーザ定義の場所にある不透明な ID アサーション トークンになります。ユーザ名/パスワード トークンは、SOAP ヘッダ (SOAP ベースのサービスの場合) または一部の非 SOAP プロキシ サービスのペイロードで許可されています。ID アサーション トークンは、HTTP ヘッダ、SOAP ヘッダ (SOAP ベースのサービスの場合)、または一部の非 SOAP プロキシ サービスのペイロードで許可されています。Oracle Service Bus ドメインには、そのトークン タイプをサポートする ID アサーション プロバイダが含まれている必要があります。
Oracle Service Bus は、認証されたユーザを使用してクライアントのセキュリティ コンテキストを確立します。カスタム トークンまたはユーザ名とパスワードを認証することによって確立されたセキュリティ コンテキストは、発信資格マッピングとアクセス制御の基礎として使用できます。
認証用のトークンを提供するクライアントの認証と認可を行うには、クライアントの資格を Oracle Service Bus ユーザにマップする ID アサーション プロバイダをコンフィグレーションする必要があります。Oracle Service Bus は、このようにマップされたユーザ名を使用してクライアントのセキュリティ コンテキストを確立します。
Oracle Service Bus で追加されたカスタム認証トークンのサポートは、2 つのカスタマ ニーズに対応しています。最初のシナリオでは、プロキシ サービス要求のメッセージ ペイロードのどこか (SOAP ヘッダなど) にユーザ名とパスワードがあります。Oracle Service Bus は、このユーザ名とパスワードを取得してユーザを認証する必要があります。
2 番目のシナリオでは、ユーザ名とパスワード以外の何らかの認証トークン (secure-token-xyz トークンなど) がメッセージに含まれます。このトークンは、HTTP ヘッダまたはメッセージ ペイロードにある場合があります。Oracle Service Bus は、このトークンを取得して認証する必要があります。どちらの場合も、認証が成功すると、セキュリティ コンテキストが確立されます。
通常、ほとんどのセキュリティ関連のコンフィグレーションはデプロイメント時に行われます。カスタム認証は、デプロイメント時にプロダクション環境に直接コンフィグレーションできるモデルに対応します。または、ステージング段階で認証をコンフィグレーションし、それをプロダクション環境にインポートすることもできます。
ユーザ名/パスワード トークンとカスタム トークンの両方が含まれるカスタム認証は、プロキシ サービス定義の不可欠な部分です。プロキシ サービスをエクスポートすると、すべてのカスタム トークンのコンフィグレーションが jar ファイルに含まれます。新しいバージョンのプロキシ サービスをインポートすると、前のコンフィグレーションは jar ファイルに含まれるコンフィグレーションで上書きされます。
IntegrationDeployer ロールまたは IntegrationAdministrator ロールのユーザのみが、カスタム トークン認証をコンフィグレーションできます。IntegrationOperator ロールまたは IntegrationMonitor ロールのユーザは、このコンフィグレーションへの読み込み専用のアクセス権を持ちます。
カスタム認証トークンによって転送レベルでクライアント要求を認証できます。カスタム トークンは HTTP ヘッダで指定します。サービス定義ウィザードの HTTP (および HTTPS) のコンフィグレーション ページで、クライアント認証をコンフィグレーションできます。HTTP および HTTPS プロキシ サービスのオプションは次のとおりです。
カスタム認証を選択した場合は、トークンを保持する HTTP ヘッダの名前とトークン タイプも指定する必要があります。
転送レベルのカスタム資格をコンフィグレーションする手順については、『Oracle Service Bus Console の使い方』のプロキシ サービスにあるプロキシ サービスの追加を参照してください。
カスタム認証トークンは、ID アサーション プロバイダ用に以前にコンフィグレーションされ、HTTP ヘッダに保持される任意のアクティブなトークン タイプになります。
使用するトークン タイプを処理する ID アサーション プロバイダのコンフィグレーション (または、作成とコンフィグレーション) が必要になります。「カスタム トークン用 ID アサーション プロバイダのコンフィグレーション」を参照してください。
転送レベルのカスタム資格をコンフィグレーションした後、「Web サービスのメッセージレベルでのセキュリティのコンフィグレーション」の手順で、さらにメッセージレベルのセキュリティをコンフィグレーションできます。
転送レベルのカスタム認証トークンは UDDI にパブリッシュされます。認証がコンフィグレーションされるたびに、HTTP 転送属性または HTTPS 転送属性の instanceParms に client-auth プロパティが表示されます。転送属性の表 (『ユーザーズ ガイド』) に記載されているように、client-auth で指定できる値は BASIC、CLIENT-CERT、および CUSTOM-TOKEN です。値が CUSTOM-TOKEN の場合は常に、token-header と token-type という 2 つのプロパティが追加されます。
| 注意·:· | Oracle Service Bus ビジネス サービスの定義では、カスタム トークンによる認証はサポートされません。client-auth が CUSTOM-TOKEN である UDDI からサービスをインポートすると、そのサービスは認証がコンフィグレーションされていないようにインポートされます。 |
Oracle Service Bus は、メッセージレベルのプロキシ サービス要求でクライアント指定のカスタム認証資格をサポートします。カスタム認証資格は、カスタム トークン、またはユーザ名とパスワードの形式になります。
Oracle Service Bus は、SOAP ヘッダ (SOAP ベースのプロキシ サービス) またはペイロード (非 SOAP プロキシ サービスの場合) でプロキシ サービスに渡されるカスタム トークンを受け取り、認証しようとします。トークンが渡されるメカニズムおよびトークン タイプを使用してプロキシ サービスをコンフィグレーションするには、プロキシ サービスのコンフィグレーション ウィザードを使用します。
また、Oracle Service Bus では、SOAP ヘッダ (SOAP ベースのプロキシ サービスの場合) または非 SOAP プロキシ サービスのペイロードで渡されるユーザ名とパスワード トークンを受け取り、認証しようとします。ユーザ名とパスワードが渡されるメカニズムを使用してプロキシ サービスをコンフィグレーションするには、プロキシ サービスのコンフィグレーション ウィザードを使用します。
現在は、以下のプロキシ サービスのメッセージレベル認証メカニズムがサポートされています。
メッセージ レベルのカスタム トークン、およびメッセージ レベルのユーザ名とパスワードが以下のバインディング タイプのプロキシ サービスでサポートされます。
カスタム ユーザ名/パスワードとカスタム トークンのコンフィグレーションは、ほぼ同じです。どちらの場合も、Oracle Service Bus で必要な情報を検索できるようにするための XPath 式を指定します。これらの XPath 式のルートは以下のとおりです。
| 注意·:· | すべての 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 アサーション プロバイダはそのトークンを Oracle Service Bus ユーザ名にマップし、ユーザ名を返します。トークンがユーザ名にマップされると、ID は「アサーション済み」となります。次に、Oracle Service Bus がこのユーザ名を使用して、クライアントのセキュリティ コンテキストを確立します。
プロキシ サービスにカスタム トークンを使用させる場合は、提供された WebLogic Server ID アサーション プロバイダを調べて、ニーズに対応しているかどうか確認します。WebLogic Server には、次のようなさまざまな ID アサーション プロバイダが含まれます。
Oracle Service Bus プロキシ サービスで、バンドルされているいずれかの ID アサーション プロバイダ (secure-token-xyz トークンなど) によって処理されないカスタム トークンを使用する場合は、まず自分 (またはサードパーティ) が、そのトークン タイプをサポートする WebLogic Server ID アサーション プロバイダを作成し、WebLogic Server Administration Console を使用してそのプロバイダをセキュリティ レルムに追加する必要があります。
ユーザの ID アサーションに使用する特定のタイプのカスタム トークンをサポートするには、ID アサーション プロバイダを開発します。複数のトークン タイプをサポートする ID アサーション プロバイダを開発できます。同じトークン タイプを検証できる複数の ID アサーション プロバイダを 1 つのセキュリティ レルムに用意できますが、実際にこの検証を実行できるのは 1 つの ID アサーション プロバイダだけです。
図 5-1 は ID アサーションのプロセスで、次のように動作します。
詳細については、『WebLogic Security について』の「ID アサーションとトークン」を参照してください。
転送レベルの ID アサーションの場合、ヘッダ値は java.lang.String として ID アサーション プロバイダに渡されます。メッセージレベルの ID アサーションの場合、XPath 式は次のように評価されます。
XmlCursor.TokenType を参照) を返すと、テキスト ノードまたは属性の文字列が渡される (XmlCursor.getStringValue() によって返される)。それ以外の場合は、1 つの XmlObject が渡されます。
これらのタスクを実行するために必要な手順は、以下の WebLogic Server ドキュメントに詳細に記載されています。
わかりやすいように、ある ID アサーション プロバイダ用のカスタム トークン タイプを作成し、そのプロバイダを WebLogic Server Administration Console でコンフィグレーションする手順について、ここで簡単に説明します。ただし、実際にタスクを実行するには WebLogic Server ドキュメントを調べる必要があります。
カスタム ID アサーション プロバイダを開発するには、次の手順を実行します。
SampleIdentityAsserterProviderImpl.java クラスです。これは、サンプル ID アサーション プロバイダの実行時クラスです。
カスタム ID アサーション プロバイダをコンフィグレーションする場合 (「Administration Console によるカスタム ID アサーション プロバイダのコンフィグレーション」を参照)、ID アサーション プロバイダのサポートするトークン タイプのリストが [サポートされている種類] フィールドに表示されます。サポートされるタイプを 0 個以上 [アクティブな種類] フィールドに入力します (上記の節の
図 5-1 を参照)。
[サポートされている種類] フィールドの内容は、カスタム ID アサーション プロバイダの MBean タイプを生成するために使用する MBean 定義ファイル (MDF) の SupportedTypes 属性から取得されます。サンプル ID アサーション プロバイダの例をコード リスト 5-1 に示します(MDF と MBean タイプの詳細については、「WebLogic MBeanMaker による MBean タイプの生成」を参照)。
<MBeanType>
...
<MBeanAttribute
Name = "SupportedTypes"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {"SamplePerimeterAtnToken"}"
/>
...
</MBeanType>
同様に、[アクティブな種類] フィールドの内容は、MBean 定義ファイル (MDF) の ActiveTypes 属性から取得されます。MDF ファイルの ActiveTypes 属性をデフォルトに設定すると、WebLogic Server Administration Console で手動設定する必要がなくなります。サンプル ID アサーション プロバイダの例をコード リスト 5-2 に示します。
<MBeanAttribute
Name= "ActiveTypes"
Type= "java.lang.String[]"
Default = "new String[] { "SamplePerimeterAtnToken" }"
/>
ActiveTypes 属性のデフォルトは便利ですが、他の ID アサーション プロバイダがそのトークン タイプを検証することがない場合にのみ行うようにします。それ以外の場合は、無効なセキュリティ レルム (ここでは、複数の ID アサーション プロバイダが同じトークン タイプを検証しようとします) をコンフィグレーションするほうが簡単です。一番良いのは、ID アサーション プロバイダのすべての MDF がデフォルトでそのトークン タイプをオフにすることです。その場合、そのトークン タイプを検証する ID アサーション プロバイダをコンフィグレーションして手作業でアクティブにすることができます。
プロトコル依存の転送コンフィグレーションのページに記述されているように、最終的には Service Bus Console を使用して、転送レベルのセキュリティ用にカスタム認証をコンフィグレーションします。ただし、この手順を実行する前に、まず使用するトークン タイプを認識する ID アサーション プロバイダをコンフィグレーションする (場合によっては、作成してからコンフィグレーションする) 必要があります。
これらのタスクを実行するために必要な手順は、以下の WebLogic Server ドキュメントに詳細に記載されています。
カスタム認証による転送レベルのセキュリティのコンフィグレーション手順は次のとおりです。
[セキュリティ] タブに記載されているように、最終的には Service Bus Console を使用して、カスタム認証によるメッセージレベルのセキュリティをコンフィグレーションします。ただし、この手順を実行する前に、まず使用するトークン タイプを認識する認証プロバイダまたは ID アサーション プロバイダをコンフィグレーションする (場合によっては、作成およびコンフィグレーションする) 必要があります。
これらのタスクを実行するために必要な手順は、以下の WebLogic Server ドキュメントに詳細に記載されています。
カスタム認証によるメッセージレベルのセキュリティのコンフィグレーション手順は次のとおりです。
コンテキスト プロパティを指定する場合は、プロバイダがプロパティ名を予測する必要があるため、おそらく独自のプロバイダを作成する必要があります。
カスタム トークンまたはカスタム ユーザ名/パスワードによって確立されるセキュリティ コンテキストは独特なものではなく、資格マッピングで使用できます。転送レベル認証とメッセージレベル認証の両方を実装すると、資格マッピングと ID の伝播に対しては常にメッセージレベルのセキュリティ コンテキストが使用されます。
たとえば、プロキシ サービスが SOAP ヘッダの secure-token-xyz トークンによってクライアントを認証する場合、マップされたサービス アカウントの検索中は認証されたサブジェクトが使用されます。サブジェクトは、発信メッセージで SAML トークンを生成するときにも使用されます。また、カスタム トークンまたはカスタム ユーザ名/パスワードと関連付けられた認証コンテキストの下で Java コールアウトが実行できます。
カスタム ユーザ名/パスワードが使用される場合は、パススルー サービス アカウントを使用すると、発信 HTTP 基本認証または発信 WS-Security ユーザ名トークン認証に対し、カスタム トークン内のユーザ名/パスワードを使用できます。
転送レベルのセキュリティ (HTTPS など) またはメッセージレベルのセキュリティ (WS-Security やカスタム トークンなど)、あるいは両方を組み合わせて、Oracle Service Bus プロキシ サービスを保護できます。つまり、Oracle Service Bus プロキシ サービスを、転送レベルの認証とメッセージレベルの認証の両方を使用してコンフィグレーションできます。
たとえば、クライアント要求を HTTP ヘッダ内のカスタム トークンによって転送レベルで認証し、Web サービス セキュリティ ヘッダ内を除く WSS セキュリティ トークン、カスタム トークン、またはユーザー名/パスワードによってメッセージ レベルで認証できます。
ただし、次の制限があります。WS-Security とメッセージレベルのカスタム トークンを組み合わせることは可能ですが、WS-Security ポリシーでは WS-Security トークンに基づくプロキシ サービス認証を要求できません。メッセージレベルのカスタム トークンと WS-Security プロキシ サービス認証は相互排他的な関係です。
|