| Oracle® Fusion Middleware Oracle Coherenceの保護 12c (12.2.1.3.0) E90210-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
クラスタの無許可の使用に対して保護するには、次のセキュリティ機能を構成する必要があります。
Oracle Coherenceアクセス・コントローラ – クラスタ・メンバー間の認可を提供します
Oracle WebLogic Server認可 – Oracle Coherenceキャッシュおよびサービスへ認可を提供します
Oracle Coherence IDトークン – Extendクライアントの認証を提供します
Oracle WebLogic ServerドメインにおけるOracle Coherenceのセキュリティの多くは、既存のセキュリティ機能を再利用します。これらの既存のセキュリティ・コンポーネントの知識が前提となっています。可能な場合は、このドキュメント内で既存のコンテンツへの参照が提供されます。
Oracle WebLogic Serverでは、アクセス・コントローラは、管理対象Coherenceサーバーのキーストアを使用してOracle Coherenceクラスタ・メンバー間のコール元IDを確立します。デモアイデンティティ・キーストアがデフォルトで使用され、それにはデフォルトのSSL ID (DemoIdentity)が含まれています。デフォルトのキーストアおよびIDは、設定の必要がなく、開発およびテストに適しています。特定のキーストアおよびIDを本番環境に作成する必要があります。『Oracle WebLogic Serverセキュリティの管理』のキーストアの構成に関する項を参照してください
この項には次のトピックが含まれます:
Oracle WebLogic Serverドメインでセキュリティ・フレームワークを有効化するには:
Oracle Coherenceセキュリティ・フレームワークでは、認証を実行する際にプリンシパル(ID)が必要です。SSLデモアイデンティティ・キーストアがデフォルトで使用され、それにはデフォルトのSSL ID (DemoIdentity)が含まれています。SSLデモ・キーストアおよびIDは通常、開発中に使用されます。本番環境では、SSLキーストアおよびIDを作成する必要があります。たとえば、Javaのkeytoolユーティリティを使用して、adminIDを含むキーストアを作成します。
keytool -genkey -v -keystore ./keystore.jks -storepass password -alias admin -keypass password -dname CN=Administrator,O=MyCompany,L=MyCity,ST=MyState
注意:
SSLキーストアおよびIDを作成する場合、そのSSLキーストアおよびIDを使用するようにOracle WebLogic Serverを構成する必要があります。さらに、クラスタ内のすべての管理対象Coherenceサーバーのキーストアに、同じSSL IDが存在する必要があります。「設定」ページの「キーストア」および「SSL」タブを使用して、管理対象CoherenceサーバーにキーストアおよびIDを構成します。
デフォルトのSSL IDをオーバーライドして、セキュリティ・フレームワークで使用するIDを指定するには:
認可ロールおよびポリシーは、キャッシュおよびサービスに明示的に構成されます。保護されることになるキャッシュ名およびサービスを知っておく必要があります。キャッシュ構成ファイルの調査によって、キャッシュ名およびサービス名が提供される場合があります。ただし、Oracle Coherenceのキャッシュ名のワイルドカード・サポートのために、アプリケーションで使用されているキャッシュ名を知っているアプリケーション開発者またはアーキテクトに確認する必要がある場合があります。たとえば、キャッシュ構成ファイル内のキャッシュ・マッピングは、ワイルドカード(*またはdist-*など)を使用する可能性があり、アプリケーションで実際に使用されているキャッシュの名前を示しません。
注意:
サービスまたはキャッシュ・リソースを削除しても、リソースに対して定義されているロールおよびポリシーは削除されません。ロールおよびポリシーは、サービスまたはキャッシュ・リソースを削除する前に、明示的に削除する必要があります。
この項には次のトピックが含まれます:
Oracle WebLogic Server認証を使用して、特定のOracle Coherenceキャッシュへのアクセスを制限できます。キャッシュ認証を指定するには:
有効なIDトークンを渡すクライアントのみに、クラスタ・サービスへのアクセスが許可されます。null IDトークンが渡される場合(Subjectのスコープ外で接続するクライアント)、クライアントはOracle WebLogic Serverの匿名ユーザーとして処理されます。Extendクライアントは、匿名ユーザーがアクセスできるキャッシュおよびサービスにアクセスできます。
注意:
IDが確立されたら、認可ポリシーを使用してそのIDを特定のキャッシュおよびサービスに制限する必要があります。「Oracle Coherenceのキャッシュおよびサービスの認可」を参照してください。
IDトークン・セキュリティでは、IDトークンを作成するIDトランスフォーマの実装、およびIDトークンを検証するアイデンティティ・アサータの実装が必要です。デフォルトのIDトランスフォーマの実装(DefaultIdentityTransformer)およびアイデンティティ・アサータの実装(DefaultIdentityAsserter)が用意されています。デフォルトの実装では、IDトークンとしてSubjectまたはPrincipalを使用します。ただし、いずれのセキュリティ・トークン・タイプもサポートする必要がある場合には(たとえばKerberosトークンのサポート)、カスタム実装を作成できます。「IDトークンを使用したクライアント接続の制限」を参照してください。
この項には次のトピックが含まれます:
IDトランスフォーマはIDトークンとIDとを関連付けます。ローカル(Oracle WebLogic Server内)のExtendクライアントの場合、デフォルトのIDトランスフォーマは置換できません。デフォルトのIDトランスフォーマは、現在のOracle WebLogic Serverユーザーを示すweblogic.security.acl.internal.AuthenticatedSubjectのタイプのトークンを渡します。
リモート(Oracle WebLogic Server外)のExtendクライアントの場合、IDトランスフォーマの実装クラスをアプリケーションのクラスパスの一部として含める必要があり、実装クラスの完全修飾名をクライアントのオペレーション・オーバーライド・ファイルに定義する必要があります。「カスタムIDトランスフォーマの有効化」を参照してください。次の例では、デフォルトのIDトランスフォーマを有効化します。
...
<security-config>
<identity-transformer>
<class-name>
com.tangosol.net.security.DefaultIdentityTransformer</class-name>
</identity-transformer>
</security-config>
...
リモートのExtendクライアントは、Subject.doASメソッド内のキャッシュ操作を実行する必要があります。次に例を示します。
Principal principal = new WLSUserImpl("user");
Subject subject = new Subject();
subject.getPrincipals().add(principal);
Subject.doAs(subject, new PrivilegedExceptionAction()
{
NamedCache cache = CacheFactory.getCache("mycache");
...
アイデンティティ・アサータは、Oracle Coherenceクラスタに対して有効化する必要があり、クライアントのIDトークンをアサート(検証)するために使用されます。ローカル(Oracle WebLogic Server内)のExtendクライアントの場合、アイデンティティ・アサータはweblogic.security.acl.internal.AuthenticatedSubjectのタイプのトークンをアサートするためにすでに有効化されています。
リモート(Oracle WebLogic Server外)のExtendクライアントの場合、カスタム・アイデンティティ・サータの実装クラスがGARにパッケージ化されている必要があります。ただし、リモートのExtendクライアントがトークンとしてnullを渡す場合、アイデンティティ・アサータは必要ありません。プロキシ・サービスがnullでないトークンを受信し、アイデンティティ・アサータの実装クラスが構成されていない場合、SecurityExceptionがスローされ、接続試行が拒否されます。
クラスタに対してアイデンティティ・アサータを有効化するには:
