17 Oracle Sales Cloud SOAP Webサービスのクライアントのセキュリティ・ポリシーの選択
OWSMは、Oracle Fusion Middlewareスタックに組み込まれた標準コンポーネントの1つです。
必要な下位レベルのセキュリティ・コンポーネントをサーバー・ポリシーとクライアント・ポリシーの管理可能な個別ユニットにパッケージ化することにより、OWSMでは、開発者と管理者がアプリケーションに関する効果的なセキュリティ保護およびアクセス制御を構築するために、微細な技術詳細を検討して評価する必要性を最小限に抑えます。Oracle Java Cloud Service - SaaS Extension (JCS - SaaS Extension)とOracle Sales Cloudは両方ともOracle Fusion Middlewareプラットフォーム上で動作するため、これらは両方ともOWSMを活用できます。
このサーバー・ポリシーと互換性を持つOWSMクライアント・ポリシーは6つ事前作成されていますが、本番事例の大部分では、使用に最適なのはSecurity Assertion Markup Language (SAML)のsaml_tokenクライアント・ポリシーです。
Oracle Sales Cloudの場合、外部に公開されたWebサービスの大部分は、伝送路経由でユーザー認証とメッセージ保護の両方を実現するOWSMサービス・ポリシー(oracle/wss11_saml_or_username_token_with_message_protection_service_policy)によって保護されます。このサービス・ポリシーと互換性を持つOWSMクライアント・ポリシーは6つ事前作成されています。この項では、これらのクライアント・ポリシーに関する詳細とともに、JCS - SaaS ExtensionアプリケーションがOracle Sales Cloud Webサービスと統合することが目標であるときに適用可能なポリシーに関する詳細について説明します。
サポートされているクライアント・セキュリティ・ポリシー
クライアント・アプリケーションからセキュアなWebサービスを起動する場合、Webサービスのサービス・ポリシーに対応するクライアント・ポリシーをアタッチする必要があります。Oracle Sales Cloud Webサービスは、Oracle Web Services Manager (OWSM)のwss11_saml_or_username_token_over_ssl_service_policyサービス・ポリシーを使用して保護されます。
Webサービスがwss11_saml_or_username_token_over_ssl_service_policyを使用して保護されている場合、クライアント・アプリケーションは次のいずれかのメカニズムを使用してSOAPクライアントを認証します。
-
WS-Security 1.1標準に準拠したSecurity Assertion Markup Language (SAML)トークンとメッセージ保護。対応するOWSMクライアント・ポリシーは、次のとおりです。
oracle/wss11_saml_token_with_message_protection_client_policy -
各SAMLトークン内にベアラー確認メソッドを備えた、WS-Security SOAPヘッダー内のSAMLトークンに用意されている資格証明を使用したSAMLベースの認証。このメカニズムのOWSMサービス・ポリシーの場合、トランスポート・プロトコルでSSL/TLSが保護されていることが必要です。対応するOWSMクライアント・ポリシーは、次のとおりです。
oracle/wss_saml_token_bearer_over_ssl_client_policy -
HTTP認可ヘッダー内のベアラー・トークンとしてのJSON Webトークン(JWT)。JWTの実装の詳細な手順は、 「Oracle Sales Cloudのマッシュアップ用のJSON Webトークンの使用」を参照してください。
クライアント・ポリシーの選択
SAMLベースの認証を使用するタイミング
Oracleでは、Oracle Sales CloudインスタンスとJCS - SaaS Extensionインスタンスを統合する場合はSAMLベースのクライアント・ポリシーを使用することをお薦めします。Oracleでは、Oracle Sales CloudインスタンスとJCS - SaaS Extensionインスタンスが同じアイデンティティ・ドメインでプロビジョニングされていた場合、これらの間でSAML設定を事前構成します。これらが異なるアイデンティティ・ドメイン内にある場合、SAMLを使用することはできず、かわりに他のメカニズムの1つを使用します。
SAMLでは、トークンの構築を大幅に自動化します。これらのクライアント・ポリシーは、一部の仕様に合わせてフォーマットされたユーザー名属性とパスワード属性が通常は含まれるトークンを構築するための効果的な代替手段です。SAMLの場合、事前構成されたSAMLインフラストラクチャを前提としています。クライアント側では、SAMLトークンはアウトバウンドSOAPリクエストに自動的に組み込まれており、SAMLログイン・モジュールは認証を目的としてトークンを分解する方法を把握しています。多くの点において、SAMLトークン・ベースのポリシーが最も実装が簡単ですが、これは、正しく動作するSAMLインフラストラクチャがすでに実装されていることが前提です。
SAMLベースの認証を使用すると、次のような明確なメリットがあります。
-
SAMLトークンを使用する場合、拡張機能サービスによってホストされるアプリケーションにサインインするユーザーのアイデンティティがOracle Sales Cloudに自動的に伝播されます。
-
SAMLトークンを使用する場合、Oracle Sales Cloudにより、SOAPコールの処理時にサインイン済ユーザーの認可ロールが適用されます。
ユーザー名トークンおよびHTTP基本ポリシーを使用するタイミング
EclipseまたはJDeveloperウィザードを使用してOracle Sales Cloud Webサービス用のWebサービス・クライアント、プロキシまたはデータ・コントロールを作成する場合、選択元のクライアント・セキュリティ・ポリシーのリストは、互換性のあるユーザー名トークンおよびHTTP基本クライアント・ポリシーに制限されます。アプリケーションのニーズに最も合うクライアント・ポリシーを選択する必要があります。
ユーザー名トークンおよびHTTP基本ポリシーでは、SOAPで有効なユーザー名とパスワードが提供されることを必要とします。つまり、拡張機能サービス上で動作するアプリケーションに、Oracle Sales Cloudへのすべてのコールに使用される1つのユーザー名とパスワードが格納されていることが必要です(これはサービス・アカウントと呼ばれます)。サービス・アカウントのパスワードが変更されると、アプリケーションを即時更新する必要があります。また、Oracle Sales Cloudでは、サインイン済ユーザーではなくサービス・アカウントに基づいて認可に関する決定を行う必要があります。
ただし、ユーザー名トークンまたはHTTP基本クライアント・ポリシーを使用する方が有益である状況が2つあります。
-
デバッグ: デバッグを目的として、ユーザー名トークン・ベースのクライアント・ポリシーに一時的に戻し、ユーザー資格証明に対する開発者の制御と可視性を強化した方が有益である場合があります。選択したポリシーにユーザー名とパスワードをハードコードでき、問題を特定のコンポーネントにより簡単に隔離できます。
-
サービス・アカウント・シナリオ: サインインしたユーザーのものとは異なる権限およびシステム・ロールを持つ可能性があるサービス・アカウントの資格証明を使用してWebサービス・コールを認証する必要があるユースケースがあります。この場合、ユーザー名トークン・ベースのクライアント・ポリシーに戻すことが効果的な方法です。
Oracle Sales Cloudサービス・ポリシーと互換性がある非SAMLベースおよび非JWTベースのOWSMクライアント・ポリシー用のオプションは、次のとおりです。
-
oracle/wss11_username_token_with_message_protection_client_policy -
oracle/wss11_username_token_over_ssl_client_policy -
oracle/wss11_http_token_over_ssl_client_policy
username_tokenポリシーには、送信SOAPリクエスト・メッセージの一部としてWS-Security UsernameToken SOAPヘッダーにユーザー資格証明を含めます。http_tokenポリシーは、送信リクエストのHTTPヘッダー・セクションに資格証明を渡します。