複数のセキュリティー・ドメイン
WebSphere® Security Domains (WSD) を使用すると、異なるセキュリティー構成を WebSphere Application Server で柔軟に使用することができます。WSD は、複数のセキュリティー・ドメイン、あるいは単にセキュリティー・ドメインとも呼ばれます。異なるアプリケーションに対して異なるセキュリティー属性 (例えば、UserRegistry) を構成できます。
- セキュリティー・ドメインが役立つ理由
- グローバル・セキュリティーとセキュリティー・ドメインの関係
- セキュリティー・ドメインの内容
- セキュリティー・ドメインの作成
- セキュリティー・ドメインの属性の構成
- セキュリティー・ドメインへの有効範囲の関連付け
- 古いサーバー・レベルのセキュリティーと新しいセキュリティー・ドメインの関係
- セキュリティー・ランタイムおよびアプリケーションによるドメイン・レベルのセキュリティー属性の使用方法
- セキュリティー・ドメインの使用時のクライアントおよびアプリケーション・セキュリティー・プログラミング・モデル
- 複数ドメイン構成におけるアプリケーション・デプロイメント
- 相互レルム通信
- ノードとセキュリティー・ドメインのフェデレート
- 混合バージョン環境でのセキュリティー・ドメイン
- セキュリティー・ドメインの変更
セキュリティー・ドメインが役立つ理由
WebSphere Security Domains には、以下の主な 2 つの利点があります。
- ユーザー・アプリケーションのセキュリティー構成とは異なるセキュリティー構成のセットを使用して、WebSphere Application Server 管理アプリケーションを構成できます。
- 1 つのアプリケーション・セットに、もう 1 つのアプリケーション・セットからの
別のセキュリティー構成セットを組み込むことができます。
例えば、WebSphere Application Server 管理は、RACF® のユーザー・レジストリーに合わせて構成できるのに対し、アプリケーションは LDAP のユーザー・レジストリーに合わせて構成できます。
例えば、アプリケーションを LDAP のユーザー・レジストリーに合わせて構成できるだけでなく、WebSphere Application Server 管理は、統合リポジトリーのユーザー・レジストリーに合わせて構成できます。
以前のバージョンの WebSphere Application Server では、すべての管理アプリケーションおよびユーザー・アプリケーションは、ほとんどのセキュリティー属性を共有します。WebSphere Application Server におけるすべての管理アプリケーションおよびユーザー・アプリケーションは、デフォルトで、グローバル・セキュリティー属性を使用します。例えば、グローバル・セキュリティーで定義されるユーザー・レジストリーは、同じセル内のすべてのアプリケーションに対して 1 人のユーザーを認証するために使用されます。
しかし、このリリースの WebSphere Application Server では、グローバル・セキュリティー属性以外の複数のセキュリティー属性をユーザー・アプリケーションに使用し、それらのセキュリティー・属性に対してセキュリティー・ドメインを作成してそれらをサーバーおよびクラスターに関連付けます。異なっている必要のあるセキュリティー属性にはセキュリティー・ドメインを作成して、それらのユーザー・アプリケーションをホストするサーバーとクラスターに、それらの属性を関連付けます。また、セキュリティー・ドメインをセルに関連付けることもできます。セル内のすべてのユーザー・アプリケーションは、それらにドメインがまだ関連付けられていない場合には、このセキュリティー・ドメインを使用します。しかし、その場合でも、例えば管理コンソール、ネーミング・リソース、MBeans などの管理アプリケーションには、グローバル・セキュリティー属性が必要です。
以前のリリースの WebSphere Application Server でサーバー・レベルのセキュリティーを使用していた場合は、より柔軟性が高く、構成しやすい複数のセキュリティー・ドメインを使用してください。
サーバー・レベルのセキュリティーは、このリリースでは非推奨になっています。詳しくは、グローバル・セキュリティーとセキュリティー・ドメインの関係を参照してください。
グローバル・セキュリティーとセキュリティー・ドメインの関係
グローバル・セキュリティーは、すべての管理機能と、ユーザー・アプリケーションのデフォルトのセキュリティー構成に適用されます。セキュリティー・ドメインは、ユーザー・アプリケーション用にカスタマイズされた構成を定義する場合に使用できます。
セキュリティー・ドメインを作成するには、その前にグローバル・セキュリティー構成を定義しておく必要があります。グローバル・セキュリティー構成は、例えば管理コンソール、ネーミング・リソース、および Mbeans になどのすべての管理アプリケーションによって使用されます。 構成されているセキュリティー・ドメインがない場合、すべてのアプリケーションはグローバル・セキュリティー構成からの情報を使用します。Enterprise JavaBeans (EJB)、サーブレット、および管理アプリケーションなどのユーザー・アプリケーションは、同じセキュリティー構成を使用します。
セキュリティー・ドメインを作成して、それを有効範囲に関連付けると、その有効範囲内のユーザー・アプリケーションだけが、そのセキュリティー・ドメインで定義されているセキュリティー属性を使用します。その有効範囲内でのネーミング操作だけでなく、管理アプリケーションも、グローバル・セキュリティー構成を使用します。グローバル・レベルにあるセキュリティー属性とは異なっている必要のあるセキュリティーは、ドメイン・レベルで定義します。情報が共通の場合は、セキュリティー・ドメインにその情報を重複して持たせる必要はありません。ドメインに欠落している属性は、グローバル構成から取得されます。グローバル・セキュリティー構成データは security.xml フィルに保管されます。このファイルは $WAS_HOME/profiles/$ProfileName/cells/$CellName ディレクトリーにあります。
下図は、セル、サーバー、およびクラスターが、異なるセキュリティー・ドメインに関連付けられているセキュリティー複数ドメインの例を示しています。 この図に示しているように、サーバー S1.1 およびクラスター内のユーザー・アプリケーションは、それぞれ Domain2 および Domain3 で定義されているセキュリティー属性を使用しています (その理由は、これらの有効範囲がこれらのドメインに関連付けられているからです)。サーバー S2.2 はドメインには関連づけられていません。そのため、S2.2 内のユーザー・アプリケーションは、デフォルトでセル (Domain1) に関連づけられているドメインを使用しています。ドメイン・レベルから欠落しているセキュリティー属性は、グローバル構成から取得されます。

下図は、グローバル・セキュリティー構成で定義できる高水準のセキュリティー属性と、ドメイン・レベルでオーバーライドできるセキュリティー属性を示しています。

セキュリティー・ドメインの内容
セキュリティー・ドメインは、2 つの構成ファイルによって表されます。 一方の構成ファイルには、セキュリティー・ドメインに構成されている属性のリストが含まれます。 もう一方の構成ファイルには、セキュリティー・ドメインを使用する有効範囲が含まれます。 セキュリティー・ドメイン情報は、$WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName ディレクトリーに保管されます。 構成されているすべてのセキュリティー・ドメインに、2 つのファイルを含む $SecurityDomainName ディレクトリーが作成されます。2 つのファイルの内、security-domain.xml ファイルには、セキュリティー・ドメイン用に構成されたセキュリティー属性のリストが含まれ、もう 1 つの security-domain-map.xml ファイルには、セキュリティー・ドメインを使用する有効範囲が含まれます。
下図は、メインのセキュリティー・ドメイン関連ファイルのロケーションと、それらのファイルの内容を示しています。

セキュリティー・ドメインの作成
セキュリティー・ドメインの作成には、管理コンソール・タスク、またはスクリプト・コマンドを使用します。 管理コンソールで、
をクリックしてセキュリティー・ドメインにアクセスします。 管理コンソール・パネルごとにヘルプを使用できます。管理コンソール・タスクおよびスクリプト・コマンドの完全なリストについては、この文書の終わりにある「関連タスク」のリンクを参照してください。
セキュリティー・ドメインを作成する場合は、ドメインの固有名、セキュリティー・ドメインに対して構成するセキュリティー属性、およびセキュリティー・ドメインを使用する必要がある有効範囲を提供する必要があります。構成が完了したら、セキュリティー・ドメインを使用するサーバーを再始動する必要があります。これにより、それらの有効範囲にあるユーザー・アプリケーションが、セキュリティー・ドメインで定義されている属性を使用します。ドメイン・レベルで構成されていない属性は、グローバル・セキュリティー構成から取得されます。有効範囲内の管理アプリケーションとネーミング操作は、常にグローバル・セキュリティー構成のセキュリティー属性を使用します。これらの属性はアクティブに管理する必要があります。
新規のセキュリティー・ドメイン属性は、ドメインに割り当てられているユーザー・アプリケーションが継承するグローバル・セキュリティー属性と互換性がなければなりません。
JAAS およびカスタム・プロパティーの場合以外は、グローバル属性があるドメイン用にカスタマイズされると、ユーザー・アプリケーションはそれらの属性を使用しなくなります。
管理コンソールのセキュリティー・ドメイン・パネルを使用すると、リソースを割り当て、ご使用のドメインにとって適切なセキュリティー属性を選択できます。このパネルには、グローバル構成にある重要なセキュリティー属性が表示されます。必要であれば、それらの属性をドメイン・レベルでオーバーライドすることもできます。属性をドメイン・レベルで構成して保存すると、このパネルの要約値に、ドメインのカスタマイズ値が表示されます (黒字で「カスタマイズ済み」という語が付けられます)。
有効範囲 (サーバー、クラスター、サービス統合バス、またはセル) は、1 つのドメインにしか関連付けられません。例えば、どちらもセル全体にわたる有効範囲を持つ 2 つのドメインは定義できません。ただし、同じセキュリティー・ドメイン内に複数の有効範囲を定義することは可能です。例えば、ドメインの有効範囲を、セル内でのみ Server1 と Server2 に設定できます。
セキュリティー・ドメイン・パネルの割り当て済み有効範囲セクションには、2 つのビューが表示されます。1 つのビューでは、有効範囲を選択してそれをドメインに割り当てることができ、もう 1 つのビューでは、現在割り当てられている有効範囲のリストを表示することができます。便宜上、既存のセキュリティー・ドメインまたはグローバル構成のすべてのセキュリティー属性を、柔軟に新規のセキュリティー・ドメインにコピーし、異なっていなければならない属性のみを変更することもできます。その場合でも、これらのコピーしたドメインに有効範囲を関連付ける必要があります。
スクリプト・コマンドを使用しても、セキュリティー・ドメインを作成、コピー、および変更することができます。 ドメインを作成したら、適切なコマンドを実行して、セキュリティー属性と有効範囲をそのドメインに関連付ける必要があります。
セキュリティー・ドメインの属性の構成
WebSphere Application Server バージョン 9.0 でドメイン・レベルで構成できるセキュリティー属性は、以下のとおりです。
- アプリケーション・セキュリティー
- Java™ 2 セキュリティー
- ユーザー・レルム (レジストリー)
- トラスト・アソシエーション
- Simple and Protected GSS-API Negotiation (SPNEGO) Web 認証
- RMI/IIOP セキュリティー (CSIv2)
- JAAS ログイン (アプリケーション、システム、および J2C 認証データ)
- Java Authentication SPI
- 認証メカニズムの属性
- 許可プロバイダー
- 統合リポジトリー
z/OS® のプロパティー
- カスタム・プロパティー
管理コンソールのセキュリティー・ドメイン・パネルには、これらの属性がすべて表示されます。
ドメイン・レベルでオーバーライドできないその他の既知の属性には、Kerberos、監査、Web シングル・サインオン (SSO)、および Tivoli® Access Manager (TAM) があります。Secure Sockets Layer (SSL) 属性は既にさまざまな有効範囲をサポートしていますが、この属性はドメイン構成の一部ではありません。 ドメイン・レベルでサポートされていないすべての属性に関しては、ドメイン内のユーザー・アプリケーションは、それらの属性のグローバル・レベルの構成を共有します。
新規のセキュリティー・ドメイン属性は、ドメインに割り当てられているユーザー・アプリケーションが継承するグローバル・セキュリティー属性と互換性がなければなりません。これらの属性はアクティブに管理する必要があります。 例えば、ある JAAS 構成のみをドメイン・レベルでカスタマイズした場合は、その構成がグローバル・レベルで構成されているユーザー・レジストリー (そのユーザー・レジストリーがドメイン・レベルでカスタマイズされていない場合) と連携することを確認する必要があります。
JAAS およびカスタム・プロパティーの場合以外は、グローバル属性があるドメイン用にカスタマイズされると、ユーザー・アプリケーションはそれらの属性を使用しなくなります。
Tivoli Access Manager のクライアント・ランタイムは、TAM サーバーに接続することによって、(TrustAssociationInterceptor および PDLoginModule によって使用される) 認証と、(JACC によって使用される) 許可を行うために使用されます。 1 つのセル内のすべてのサーバーによって共有される Tivoli Access Manager ランタイムは 1 つだけです。詳しくは、『Tivoli Access Manager JACC プロバイダー構成』トピックを参照してください。
セキュリティー・ドメイン・レベルの別の Tivoli Access Manager 構成で、セル・レベルの構成をオーバーライドすることはできません。ただし、セキュリティー・ドメイン・レベルである程度までトラスト・アソシエーション・インターセプター (TAI) および JACC 構成を指定できます。 例えば、異なる TAI または異なる許可プロバイダーを使用することができます。 TAM サーバー接続はグローバル・レベルでしか定義できないため、セキュリティー・ドメイン・レベルでさまざまな TAI を定義し、構成することができます。 これらの TAI の中には、TAM ユーザー・リポジトリーを使用しない可能性があるものもありますが、これを使用するものもあります。 TAM への接続を必要とする TAI は、グローバルに定義された TAM サーバーにも接続します。 許可の場合も同様に、さまざまな外部許可プロバイダーをドメイン・レベルで構成することができます。 ただし、これらの外部許可プロバイダーのいずれかが TAM への接続を必要とする場合、そのプロバイダーは最終的にはグローバルに構成された一つの TAM サーバーと通信を行うことになります。
セキュリティー・ドメインへの有効範囲の関連付け
クラスターの一部ではないサーバーにセキュリティー・ドメインが関連付けられている場合、 そのサーバー内のすべてのユーザー・アプリケーションは、 そのセキュリティー・ドメインからの属性を使用します。 欠落しているセキュリティー属性は、グローバル・セキュリティー構成から取得されます。 サーバーがクラスターの一部である場合は、 セキュリティー・ドメインをそのクラスターに関連付けることができますが、 そのクラスター内の個々のメンバーに関連付けることはできません。 したがって、セキュリティーの動作は、 すべてのクラスター・メンバーに渡って一貫性のあるものになります。
サーバーをクラスターの一部にする場合は、 最初にクラスターを作成し、セキュリティー・ドメインをそのクラスターに関連付けます。 サーバーがクラスターのメンバーとなる前に、そのドメインをサーバーに関連付けていることもあります。 そのような場合は、ドメインがサーバーに直接関連付けられていても、 セキュリティー・ランタイム・コードはそのドメインを調べることはありません。 サーバーがクラスター・メンバーの場合、セキュリティー・ランタイムは、 そのサーバーに直接関連付けられているセキュリティー・ドメインをすべて無視します。 セキュリティー・ドメインからサーバー有効範囲を除去し、 その代わりにクラスター有効範囲をセキュリティー・ドメインに関連付けます。
セキュリティー・ドメインをセルに関連付けることもできます。 この関連付けは、通常、WebSphere Application Server 内のすべてのユーザー・アプリケーションをセキュリティー・ドメインに関連付ける場合に行われます。 このシナリオでは、すべての管理アプリケーションとネーミング操作は、 グローバル・セキュリティー構成を使用するのに対し、 すべてのユーザー・アプリケーションは、ドメイン・レベルの構成を使用します。 管理アプリケーションおよびユーザー・アプリケーションの セキュリティー構成情報を分割するのであれば、これ以上のことを行う必要はありません。
環境が混合バージョン環境の場合、または将来混合バージョン環境を導入する計画があり、 セキュリティー・ドメインをセル・レベルで関連付けたい場合は、 その詳細について混合バージョン環境でのセキュリティー・ドメインを参照してください。
独自のセキュリティー・ドメインを定義している Base プロファイル・サーバーを使用しており、 その Base プロファイルをデプロイメント・マネージャーに統合する場合は、 セキュリティー・ドメインの有効範囲をセルではなくサーバーとしてください。 そのノードをフェデレートすると、セキュリティー・ドメイン情報がデプロイメント・マネージャーに伝搬されます。セル有効範囲がデプロイメント・マネージャーに関連付けられている場合、ネットワーク・デプロイメント構成はこのセキュリティー構成を使用しますが、これによって既存のアプリケーションが影響を受ける可能性があります。セル有効範囲は、フェデレーション中に、フェデレートされているサーバー有効範囲に変更されます。サーバー有効範囲がセキュリティー・ドメインに関連付けられている場合は、フェデレーション後にセキュリティー・ドメインを使用するのは、そのサーバーのみになります。 他のサーバーおよびクラスター内の他のアプリケーションは影響を受けません。ただし、 この Base プロファイル・サーバーが管理エージェント・プロセスに登録されており、 基本プロファイルからのすべてのサーバーが、そのすべてのユーザー・アプリケーションに対して 同じセキュリティー・ドメインを使用するようにしたい場合は、 セル有効範囲をセキュリティー・ドメインに関連付けることができます。 詳しくは、ノードとセキュリティー・ドメインのフェデレートを参照してください。
あるセキュリティー・ドメインをセル・レベルで関連付け、他のセキュリティー・ドメインも、さまざまなクラスターまたは個々のサーバー (どのクラスターの一部でもないサーバー) に関連付けておくことができます。この場合、セキュリティー・ランタイムは、最初に、サーバーまたはクラスターに関連付けられているセキュリティー・ドメインがないかチェックします。サーバーまたはクラスターに関連付けられているセキュリティー・ドメインがある場合は、そのサーバーまたはクラスターで定義されているセキュリティー属性が、そのサーバーまたはクラスター内のすべてのアプリケーションに使用されます。このサーバーまたはクラスター・ドメインから欠落しているセキュリティー属性は、すべてグローバル・セキュリティー構成から取得され、セルに関連付けられているドメイン構成からは取得されません。
サーバーまたはクラスターに独自のドメインが定義されていない場合、セキュリティー・ランタイム・コードは、セルが定義されている場合は、そのセルに関連付けられているドメインからのセキュリティー属性を使用します。セル・ドメインから欠落しているセキュリティー属性は、すべてグローバル・セキュリティー構成から継承されます。
古いサーバー・レベルのセキュリティーと新しいセキュリティー・ドメインの関係
以前のリリースの WebSphere Application Server では、サーバー・レベルの少数のセキュリティー属性のセットを関連付けることができました。 これらの属性は、サーバー・レベルのすべてのアプリケーションで使用されていました。セキュリティー属性のこの従来の構成方法は、WebSphere Application Server 7.0 では非推奨になっており、将来のリリースでは除去される予定です。
WebSphere Application Server 7.0 からは、新しいセキュリティー・ドメインのサポートのご使用を推奨します。これらのセキュリティー・ドメインは、より管理しやすく、より柔軟になっています。例えば、以前のバージョンの WebSphere Application Server では、すべてのクラスター・メンバーに同じセキュリティー構成を手動で関連付けるためには、クラスター内のすべてのサーバーに同じセキュリティー属性を構成する必要がありました。
スクリプトの互換モードが false になっている場合 (-scriptCompatibility="false")、マイグレーション・ツールを使用すると、既存のサーバー・レベルのセキュリティー構成情報が、新しいセキュリティー・ドメイン構成にマイグレーションされます。 サーバー・セキュリティー構成がクラスターの一部でない場合は、すべてのサーバー・セキュリティー構成に対して新規のセキュリティー・ドメインが作成されます。サーバー・セキュリティー構成がクラスターの一部である場合、セキュリティー・ドメインは、そのクラスター内のすべてのサーバーにではなく、そのクラスターに関連付けられます。どちらの場合も、以前のリリースでサーバー・レベルで構成されたすべてのセキュリティー属性は、新しいセキュリティー・ドメイン構成にマイグレーションされ、セキュリティー・ドメインに適切な有効範囲が割り当てられます。
スクリプトの互換モードが true に設定されている場合、サーバー・レベルのセキュリティー構成は、新規のセキュリティー・ドメイン構成にマイグレーションされません。古いサーバー・セキュリティー構成は、変更がないままマイグレーションされます。セキュリティー・ドメインが直接的または間接的にサーバーに関連付けられている場合でも、セキュリティー・ランタイムは、古いセキュリティー構成が存在し、その情報を使用していることを検出します。スクリプトの互換モードが true に設定されている場合は、サーバー・レベルからセキュリティー構成を除去し、次に同じセキュリティー属性セットを使用して、セキュリティー・ドメインを作成します。
セキュリティー・ランタイムおよびアプリケーションによるドメイン・レベルのセキュリティー属性の使用方法
このセクションでは、ドメイン・レベルの個々の属性をセキュリティー・ランタイムがどのように使用し、そのことによってユーザー・アプリケーションのセキュリティーがどのような影響を受けるのかについて説明します。これらのすべてのセキュリティー属性は、グローバル・レベルでも定義されているため、これらの属性についての詳細は、別のところで入手できます。このセクションの目的に沿うよう、ドメイン・レベルの動作に重点が置かれています。
- アプリケーション・セキュリティー:
「アプリケーション・セキュリティーを使用可能にする」を選択するかどうかによって、ユーザー・アプリケーションに対するセキュリティーを使用可能または使用不可に設定します。 この選択を使用不可に設定すると、 セキュリティー・ドメイン内のすべての EJB および Web アプリケーションは、保護されなくなります。 これらのリソースに対するアクセス権限は、ユーザー認証を行わずに付与されます。 この選択を使用可能に設定すると、J2EE セキュリティーは、 セキュリティー・ドメイン内の EJB および Web アプリケーションのすべてに実行されます。 J2EE セキュリティーが実行されるのは、グローバル・セキュリティー構成でグローバル・セキュリティーが有効になっている場合だけです (すなわち、アプリケーション・セキュリティーを使用可能にする場合は、必ず最初にグローバル・セキュリティーをグローバル・レベルで使用可能にする必要があります)。
- Java 2 セキュリティー:
「Java 2 セキュリティーを使用」を選択して、Java 2 セキュリティーをドメイン・レベルで使用可能または使用不可にするか、あるいは、Java 2 セキュリティーに関連するプロパティーを割り当てるかまたは追加します。この選択により Java 2 セキュリティーをプロセス (JVM) レベルで使用可能または使用不可にすることで、すべてのアプリケーション (管理およびユーザーの両方) が Java 2 セキュリティーを使用可能または使用不可にできます。
- ユーザー・レルム (ユーザー・レジストリー):
このセクションにより、セキュリティー・ドメインのユーザー・レジストリーを構成できます。ドメイン・レベルで使用されるすべてのレジストリーを個別に構成できます。詳しくは、セキュリティー・ドメインの属性の構成を参照してください。
レジストリーをドメイン・レベルで構成する場合は、そのレジストリーに独自のレルム名を定義することもできます。レルム名は、レジストリーを区別します。レルム名は、複数の環境 (ユーザーにプロンプトを表示する Java クライアント・ログイン・パネル内、認証キャッシュ内、およびネイティブ許可の使用時) で使用されます。
システムは、グローバル構成レベルでユーザー・レジストリー用のレルムを作成します。以前のリリースの WebSphere Application Server では、システムには 1 つのユーザー・レジストリーのみ構成されます。 セキュリティー・ドメインが複数ある場合は、システム内に複数のレジストリーを構成できます。 これらのドメインでレルムを固有にするには、セキュリティー・ドメインに対して独自のレルム名を構成します。作成されるレルム名が固有であることが明確な場合は、システムにその固有のレルム名を作成させることもできます。後者の場合、レルム名は使用されているレジストリーに基づきます。
LDAP レジストリーの場合、LDAP サーバーの host:port はシステムが生成したレルム名です。localOS の場合は、localOS マシンの名前がレルム名です。カスタム・ユーザー・レジストリーの場合、レルムは、カスタム・レジストリー実装の getRealm ( ) メソッドによって返されるレルムです。
システムが生成したレルム名が十分な範囲で固有な場合は、システムがレルム名を生成するためのオプションを選択できます。選択しない場合は、ユーザー・レジストリーを構成するセキュリティー・ドメインごとに、固有のレルム名を選択してください。基礎となるユーザー・リポジトリーが同一の場合は、異なるドメインで同一のレルム名を使用します。セキュリティー・ランタイムの観点からは、同一のレルム名は、同一のユーザーおよびグループ情報のセットを持ちます。例えば、ユーザーおよびグループの情報がレルムから要求された場合、そのレルムに一致する最初のユーザー・リポジトリーが使用されます。
集中型以外の localOS レジストリーが任意のドメインに構成され、そのドメインがデプロイメント・マネージャーと同じシステム上にないノードのサーバーまたはクラスターに関連付けられている場合、レルム名を指定する必要があります。 このレルム名は、ノードで生成される場合と同じ名前にする必要があります。ノード上の SecurityAdmin MBean の getRealm() メソッドを呼び出すことで、このレルム名を取得できます。 通常は、localOS レジストリーのレルム名がマシンのホスト名になります。 この場合、システムでレルム名を生成するのではなく、ノード内のプロセスで使用されるレルム名を取得する必要があります。ユーザー・レジストリーを構成する際に localOS レジストリーのレルムを生成するようにシステムを選択した場合、デプロイメント・マネージャーで使用する localOS レジストリーが選択されます。 構成したレルムがサーバーで使用されるレルムと一致しない場合は、許可に問題があります。 また、この場合、このローカル・レジストリーを使用するドメインに関連付けが可能なのは、同じマシン上のノードに属しているサーバーおよびクラスターのみであることに注意してください。
WebSphere Application Server バージョン 7.0 では、統合リポジトリー・ユーザー・レジストリーはグローバル・レベルでのみ構成可能であり、セルごとに 1 つのインスタンスしか持ちませんが、アクティブ・レジストリーとして構成することで、すべてのドメインがそのレジストリーを使用できるようになります。WebSphere Application Server バージョン 8.0 では、複数のセキュリティー・ドメイン環境において、統合リポジトリーの固有のインスタンスをドメイン・レベルで構成できます。
グローバル・レベルからセキュリティー・ドメインをコピーすると、グローバル・レベルで定義されているユーザーとグループもセキュリティー・ドメインにコピーされます。これは既存ドメインからコピーする場合も適用されます。新しく作成する セキュリティー・ドメインがファイル・ベースの VMM リポジトリーを使用する場合は、ユーザーが リポジトリーにユーザーおよびグループを取り込む必要があります。
ほかにもこのリリースの WebSphere Application Server の新機能として、「レルム構成設定 (Realm configurations settings)」管理コンソール・ページの新しいチェック・ボックスである「モデルにグローバル・スキーマを使用 (Use global schema for model)」があります。これは、複数のセキュリティー・ドメイン環境でデータ・モデルにグローバル・スキーマ・オプションを設定します。 グローバル・スキーマとは、管理ドメインのスキーマを指します。
複数のユーザー・レジストリーが 1 つのプロセス内にある場合、「UserRegistry」を検索名として使用するネーミング検索は、ユーザー・アプリケーションが使用するユーザー・レジストリーを返します。管理アプリケーションが使用するユーザー・レジストリーは、検索名「AdminUserRegistry」によりバインドされます。
相互レルム通信で説明しているように、あるレルム内のあるアプリケーションが、LTPA トークンを使用して別のレルム内のあるアプリケーションと通信している場合、それらのレルムは信頼できるものである必要があります。この信頼関係は、ユーザー・レジストリー・パネルの「トラステッド認証レルム – インバウンド」リンクを使用するか、addTrustedRealms コマンドを使用して確立できます。異なるレルム間にも信頼関係を確立できます。あるレルムにログインしたユーザーでも、別のレルム内のリソースにアクセスできます。これら 2 つのレルム間に信頼関係が確立されていない場合、LTPA トークンの妥当性検査は失敗します。
注: web.xml ファイルで使用されているレルム名は、ユーザー・レジストリー・レルムとは関係ありません。 - トラスト・アソシエーション:
トラスト・アソシエーション・インターセプター (TAI) をドメイン・レベルで構成すると、便宜上、グローバル・レベルで構成されたインターセプターがドメイン・レベルにコピーされます。ニーズに合わせて、インターセプター・リストをドメイン・レベルで変更できます。 ドメイン・レベルで使用する予定のインターセプターのみを構成してください。
Tivoli Access Manager のトラスト・アソシエーション・インターセプターは、グローバル・レベルでしか構成できません。ドメイン構成もそれらのインターセプターを使用できますが、異なるバージョンのトラスト・アソシエーション・インターセプターを持つことはできません。セルに存在できるのは、Tivoli Access Manager のトラスト・アソシエーション・インターセプターの 1 つのインスタンスのみです。
- SPNEGO Web 認証:
SPNEGO Web 認証は、Web リソース認証用の SPNEGO の構成を可能にし、ドメイン・レベルで構成できます。
注: WebSphere Application Server バージョン 6.1 では、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用して、保護されているリソースに対する HTTP 要求を安全にネゴシエーションし、認証する TAI が導入されました。WebSphere Application Server 7.0 では、この機能は推奨されなくなりました。 代わりに、SPNEGO フィルターの動的再ロードを提供し、アプリケーション・ログイン方式へのフォールバックを可能にするために、SPNEGO Web 認証が用意されています。 - RMI/IIOP セキュリティー (CSIv2):
RMI/IIOP セキュリティー属性は、CSIv2 (Common Secure Interoperability Version 2) プロトコル・プロパティーを参照します。これらの属性をドメイン・レベルで構成すると、便宜上、グローバル・レベルの RMI/IIOP セキュリティー構成がコピーされます。
ドメイン・レベルでは別のものを使用する必要がある属性を変更することができます。 CSIv2 インバウンド通信のトランスポート層設定は、グローバル・レベルとドメイン・レベルの両方で一致している必要があります。 一致していない場合、ドメイン・レベルの属性が、プロセス内のすべてのアプリケーションに適用されます。
プロセスが、異なるレルムを使用して別のプロセスと通信している場合、アウトバウンド・トラステッド認証レルムのリストにダウンストリーム・サーバーがリストされていない限り、LTPA 認証および伝搬トークンはそのダウンストリーム・サーバーには伝搬されません。アウトバウンド・トラステッド認証レルムのリストにダウンストリーム・サーバーをリストするには、「CSIv2 – アウトバウンド通信 (CSIv2 outbound communication)」パネルの「トラステッド認証レルム アウトバウンド (Trusted authentication realms outbound)」リンクを使用するか、addTrustedRealms コマンド・タスクを使用します。詳しくは、相互レルム通信を参照してください。
- JAAS (Java 認証・承認サービス):
JAAS アプリケーション・ログイン、JAAS システム・ログイン、および JAAS J2C 認証データ別名は、すべてドメイン・レベルで構成できます。 デフォルトでは、システム内のすべてのアプリケーションは、グローバル・レベルで構成されている JAAS ログインにアクセスできます。 セキュリティー・ランタイムは、最初に、ドメイン・レベルの JAAS ログインがないか確認します。見つからない場合は、グローバル・セキュリティー構成の JAAS ログインを調べます。セキュリティー・ドメイン内のアプリケーションが排他的に使用するログインを指定する必要がある場合にのみ、これらの JAAS ログインのいずれかをドメインで構成します。
JAAS およびカスタム・プロパティーの場合にのみ、グローバル属性をあるドメイン用にカスタマイズしても、ユーザー・アプリケーションはそれらの属性を使用することができます。
- Java Authentication SPI
(JASPI)
ドメイン・レベルで適用される Java Authentication SPI (JASPI) 認証プロバイダーおよびその関連認証モジュールの構成設定を指定します。
「プロバイダー」を選択して、JASPI 認証プロバイダーを作成または編集します。
注: JASPI 認証プロバイダーは、ドメイン・レベルで構成されたプロバイダーで有効にすることができます。デフォルトでは、システム内のすべてのアプリケーションは、グローバル・レベルで構成されている JASPI 認証プロバイダーにアクセスできます。セキュリティー・ランタイムは、初めにドメイン・レベルの JASPI 認証プロバイダーがあるかどうかを検査します。 見つからない場合は、グローバル・セキュリティー構成内の JAAS ログインを調べます。 JASPI 認証プロバイダーは、セキュリティー・ドメイン内のアプリケーションによって排他的に使用する場合にのみ、そのドメインで構成してください。 - 認証メカニズムの属性:
ドメイン・レベルで適用する必要のある各種キャッシュ設定を指定します。
- 認証キャッシュの設定 - 認証キャッシュの設定値を指定する場合に使用します。このパネルで指定した構成は、このドメインにのみ適用されます。
- LTPA タイムアウト - ドメイン・レベルの別の LTPA タイムアウト値を構成できます。デフォルトのタイムアウト値は 120 分です。この値はグローバル・レベルで設定されます。LTPA タイムアウトがドメイン・レベルで設定されると、ユーザー・アプリケーションへのアクセス時にセキュリティー・ドメインで作成されるトークンは、この有効期限の時間に基づいて作成されます。
- レルム修飾されたユーザー名を使用 - この選択が有効になっている場合、getUserPrincipal( ) などのメソッドによって返されるユーザー名は、セキュリティー・ドメイン内のアプリケーションが使用するセキュリティー・レルム (ユーザー・レジストリー) で修飾されます。
- 許可プロバイダー:
外部のサード・パーティー JACC (Java Authorization Contract for Containers) プロバイダーをドメイン・レベルで構成できます。Tivoli Access Manager の JACC プロバイダーは、グローバル・レベルでしか構成できません。 セキュリティー・ドメインは、別の JACC プロバイダーで許可プロバイダーをオーバーライドしなければ、引き続き使用できます。
例えば、ポリシー・オブジェクトなどの JACC 属性は、JVM レベルがベースになります。これは、JVM プロセスに JACC ポリシー・オブジェクトを 1 つしか含めることができないことを意味しています。 ただし、複数の JACC プロバイダーを構成した場合、デプロイメント・マネージャーのプロセスで、同じ JVM にあるすべてのプロバイダーを処理する必要があります。その理由は、アプリケーションの許可ポリシーをアプリケーション名に応じてそれぞれのプロバイダーに伝搬する必要があるからです。
JACC プロバイダーで許可ポリシーの複数プロバイダーへの伝搬処理が可能な場合は、グローバル・レベルで構成することができます。この場合、アプリケーションのインストール時に、JACC プロバイダーがデプロイメント・マネージャー・プロセスで呼び出され、この JACC プロバイダーによって、contextID で渡されたアプリケーション名に基づいて対応する JACC プロバイダーに情報が伝搬されます。
この処理の別の方法として、カスタム・プロパティー com.ibm.websphere.security.allowMultipleJaccProviders=true をグローバル・セキュリティー・レベルで設定する方法があります。 このプロパティーを設定すれば、アプリケーションがインストールされているターゲット・サーバーに対応するドメインに関連付けられた JACC プロバイダーに許可ポリシーの情報が、WebSphere Application Server によって伝搬されます。このプロパティーは、管理対象サーバーが複数の JACC プロバイダーをホストしていないため、デプロイメント・マネージャー・プロセスでのみ使用されます。
さらに、以下のような SAF 許可オプションをセキュリティー・ドメイン・レベルで構成することもできます。
- 非認証ユーザー ID
- SAF プロファイル・マッパー
- SAF 委任を使用可能にするかどうか
- WebSphere Application Server へのアクセスを制限するために APPL プロファイルを使用するかどうか
- 許可に失敗したメッセージを抑止するかどうか
- SMF 監査レコード計画
- SAF プロファイル接頭部
CBIND 検査は管理操作と見なされるため、指定されている SAF プロファイル接頭部のグローバル・レベルの値は、検査対象の CBIND リソースの名前を決定する際に使用されます。 例えば、CB.BIND.<cluster_name または SAF_profile_prefix> などとなります。
SAF 許可オプションについて詳しくは、z/OS System Authorization Facility 許可を参照してください。
- カスタム・プロパティー:
新規のカスタム・プロパティー、またはグローバル・レベルのものとは異なるカスタム・プロパティーをドメイン・レベルで設定します。 デフォルトでは、グローバル・セキュリティー構成のカスタム・プロパティーはすべて、 セル内のすべてのアプリケーションからアクセスできます。 セキュリティー・ランタイム・コードは、最初に、ドメイン・レベルにカスタム・プロパティーがないか確認します。 見つからない場合は、グローバル・セキュリティー構成のカスタム・プロパティーを取得しようとします。
JAAS およびカスタム・プロパティーの場合にのみ、グローバル属性をあるドメイン用にカスタマイズしても、ユーザー・アプリケーションはそれらの属性を使用することができます。
セキュリティー・ドメインの使用時のクライアントおよびアプリケーション・セキュリティー・プログラミング・モデル
EJB にアクセスするクライアントとして動作する Java クライアントまたはアプリケーションは、一般に最初にネーミング検索を実行します。ネーミング・リソースは、管理アプリケーションおよびユーザー・アプリケーションの両方によって使用され、管理リソースとみなされます。ネーミング・リソースは、グローバル・セキュリティー構成情報によって保護されます。グローバル・セキュリティーがあるレルム (ユーザー・レジストリー) を使用し、ドメインがそれとは異なるレルムを使用している複数ドメイン・セットアップでは、Java クライアントは 2 つの異なるレルムにより認証を受ける必要があります。 最初の認証は、ネーミング操作を正常に行うために、グローバル・セキュリティー構成内のレルムに対して必要で、2 つ目の認証は、異なるレルムを使用している EJB にアクセスするために必要です。
すべてのネーミング読み取り操作は、CosNamingRead ロールによって保護されます。このロールには、通常 Everyone 特別サブジェクトが割り当てられます。これは、すべてのユーザーは有効であるかそうでないかには関係なく名前空間を検索できる、ということを暗黙で意味しています。 複数ドメインが定義されている場合、CosNamingRead ロールが Everyone 特別サブジェクトを持っていると、クライアント側のセキュリティー・ランタイム・コードは、ログインを促すプロンプトを表示しません。その代わりにこのセキュリティー・ランタイム・コードは、非認証サブジェクトを使用してネーミング操作にアクセスします。ネーミング検索操作が完了して、クライアントが EJB にアクセスしようとすると、現在 EJB アプリケーションが使用しているレルム (すなわち、ドメインで使用されているレルム) を示すログイン・パネルがプロンプトとしてクライアントに表示されます。クライアントはそのレルムに対応する適切なユーザー・クレデンシャルを提供することにより、EJB にアクセスできます。このロジックは、ログイン・ソースが prompt に設定されている場合だけでなく、properties および stdin を含む、ログイン・ソースのすべてのバリエーションに適用されます。
Everyone 特別サブジェクトが CosNamingRead ロールから除去されると、プロンプトが 2 回表示されます。ログイン・ソースが properties の場合は、$WAS_HOME/profiles/$ProfileName/properties/sas.client.props ファイル内の com.ibm.CORBA.loginRealm プロパティーのコメントを外し、分離文字として「|」を使用して適切なレルムを追加します。com.ibm.CORBA.loginUserid および com.ibm.CORBA.loginPassword プロパティーに、それぞれ対応するユーザーとパスワードを入力する必要もあります。Java クライアント・コードでプログラマチック・ログオンを使用している場合は、異なるユーザー・クレデンシャルを用いて認証を 2 回受ける必要があります。最初は、EJB に対してネーミング検索を行う前 (ユーザーはグローバル・レルムに入っている必要があります)、そしてその後の、EJB のメソッドを呼び出す前です (ユーザーは EJB ドメインのレルムに入っている必要があります)。
z/OS セキュリティー・サーバーに定義された
CosNamingRead ロールは、SAF 許可が有効な場合でも、ネーミング読み取り操作を複数のセキュリティー・ドメイン環境で保護するかどうかを決定する際に参照されません。代わりに、admin-authz.xml ファイルの設定が使用されます。 あるいは、カスタム・プロパティーの com.ibm.security.multiDomain.setNamingReadUnprotected を使用して、ネーミング読み取り操作の保護を制御することもできます。このプロパティーによって、使用する許可プロバイダーに関係なく、CosNamingRead ロールに対する割り当てがすべてオーバーライドされます。
一般に、Java クライアントが、複数の異なるレルムによって認証を受ける必要がある場合、そのクライアントは、それらのすべてのレルムにクレデンシャルを提供する必要があります。 ログイン・ソースが prompt または stdin の場合、各レルムに 1 回ずつ、複数回ログインするようにプロンプトが出ます。ログイン・ソースが properties に設定されている場合、異なるレルムへの認証には、sas.client.props ファイル (または関連するファイル) 内の該当するプロパティーが使用されます。
シナリオによっては、クライアントが複数回同じレルムを呼び出すことがあります。例えば、Java クライアントは、realm1 を使用してリソースにアクセスし、その後に realm2 を使用してあるリソースに接続し、続いてもう一度 realm1 内のリソースにアクセスすることができます。 この場合、このクライアントに対しては、3 回、すなわち最初は realm1 に対して、2 回目は realm2 に対して、そして最後にもう一度 realm1 に対してプロンプトが出ます。
デフォルトでは、レルムでログインするために使用されるサブジェクトは、クライアント側のコードによってはキャッシュされません。このシナリオがあり、レルムに基づいてサブジェクトをクライアントにキャッシュさせたい場合は、sas.client.props ファイル内で com.ibm.CSI.isRealmSubjectLookupEnabled プロパティーを true に設定します。com.ibm.CSI.isRealmSubjectLookupEnabled プロパティーが設定されていると、クライアント・コードはレルム名に基づくサブジェクトをキャッシュします。 次回、Java クライアントがこのレルムによる認証を受ける必要が生じた場合は、そのキャッシュを見つけてサブジェクトが取得されるので、クライアントに対してはプロンプトは出ません。また、com.ibm.CSI.isRealmSubjectLookupEnabled プロパティーが設定されている場合は、最初にログインしたのと同じサブジェクトが以降のログインにも使用されます。サブジェクト情報を変更する必要がある場合は、このプロパティーを設定しないでください。
クライアントがプログラマチック・ログインを実行している場合、そのクライアントは、認証に必要なユーザーとパスワードとともに、レルムを渡すことができます。この場合、sas.client.props ファイルで com.ibm.CORBA.validateBasicAuth プロパティーが true (デフォルト値) に設定されていると、レルム名に一致するレジストリーがログインに使用されます。 認証が行われるプロセスでは、そのレルムがサポートされている必要があります。
WSLogin JAAS 構成を使用している場合、レルム名をコールバック・ハンドラーに渡すには、$WAS_HOME/profiles/$ProfileName/properties 内の wsjaas_client.config ファイルで use_realm_callback オプションも設定する必要があります。 ネーム・サーバーに別のプロバイダー URL を指定する場合は、use_appcontext_callback オプションを設定し、ハッシュ・マップ内のプロバイダー URL のプロパティーを WSLogin に渡します。
レルム名が不明の場合は、<default> をレルム名として使用してください。 認証はアプリケーション・レルムに対して実行されます。ネーミング読み取り操作に Everyone 特別サブジェクトが割り当てられていない場合、検索操作を正常に行うためには、管理アプリケーションが使用するレルム (グローバル・セキュリティー構成で使用されるレジストリー) を、そのレジストリー内のユーザーおよびパスワードの情報とともに提供する必要があります。
検索操作が正常に完了した後に、アプリケーション・レルム (または <default>) と、アプリケーションが使用する レジストリー内の該当するユーザーのユーザーおよびパスワード情報を提供して、別のプログラマチック・ログインを実行します。これは、ログイン・ソースが prompt の場合に似ています。認証は 2 回行う必要があります。1 回は、グローバル・セキュリティー構成が (ネーミング検索操作のために) 使用するレジストリーに対して、もう 1 回は、アプリケーションが EJB にアクセスするために使用するレジストリーに対してです。
com.ibm.CORBA.validateBasicAuth が $WAS_HOME/profiles/$ProfileName/properties/sas.client.props ファイルで false に設定されている場合は、プログラマチック・ログインで、検索操作および EJB 操作の両方に対して、<default> をレルム名として使用できます。実際の認証は、リソースがサーバー側でアクセスされる場合にのみ行われます。その場合、レルムはアクセスされるリソースに基づいて計算されます。
WebSphere Application バージョン 7.0 で導入された新しいセキュリティー・ドメインのサポートでは、現行のアプリケーション・セキュリティー・プログラミング・モデルは変更されていません。 ただし、以下のように柔軟性が増し、機能も増えています。
- ユーザー・アプリケーションは「UserRegistry」に対するネーミングの検索を使用して、ユーザー・レジストリー・オブジェクトを見つけることができます。管理アプリケーションが使用するレジストリー・オブジェクトの場合は、「AdminUserRegistry」に対するネーミングの検索を使用できます。
- 複数ドメイン・セットアップでは、アプリケーションによる JAAS ログイン構成の使用法は変更されていません。ただし、ドメイン・レベルで指定されている JAAS 構成をアプリケーションが参照する必要がある場合、そのアプリケーションの管理者およびデプロイヤーは、このドメインが、アプリケーションが要求している JAAS 構成で構成されていることを確認する必要があります。
- アプリケーションが、異なるレルムを使用している他のアプリケーションと通信する必要がある場合は、LTPA トークンの使用時に、インバウンド通信とアウトバウンド通信の両方に対して信頼関係を確立する必要があります。詳しくは、相互レルム通信を参照してください。
- アプリケーションでプログラマチック・ログインを使用している場合、アプリケーションが使用するレルムにログインするには、レルム名として <default> を使用するか、またはアプリケーションが使用しているレルム名を提供します。グローバル・レルムにログインする必要がある場合は、グローバル・レルム名を提供する必要があります。それ以外のレルムを提供した場合は、基本認証サブジェクトのみが作成されます。そのレルムをホストしているサーバーに要求が実際に送られた場合、そのユーザーが実際に認証されるのは、そのサーバーがレルムをホストしている場合です。サーバーがレルムをホストしていない場合、ログインは失敗します。
複数ドメイン構成におけるアプリケーション・デプロイメント
複数ドメインのセットアップでアプリケーションをデプロイする場合は、同じセキュリティー・ドメインに属するサーバーまたはクラスターに、アプリケーション内のすべてのモジュールをインストールする必要があります。そのようにインストールしなかった場合、これらのセキュリティー・ドメインに構成されているセキュリティー属性によっては、動作の一貫性が失われる可能性があります。例えば、ドメインにさまざまなユーザー・レジストリーが含まれている場合、ユーザーおよびグループ情報が異なり、そのために、モジュールへのアクセス時の動作の一貫性が失われる可能性があります。別の例は、JAAS データがセキュリティー・ドメイン間で異なっている場合です。アプリケーション内のすべてのモジュールから JAAS 構成にアクセスできるわけではありません。ユーザー・レジストリー、JAAS ログイン構成、J2C 認証データ、および許可などの属性を扱う場合、セキュリティー・ランタイム・コードおよびコマンド・タスクは、あるアプリケーションに関連付けられている 1 つのドメインに依存します。
複数の異なるドメインにわたってアプリケーションをデプロイすると、ほとんどの場合にアプリケーション・デプロイメントは失敗します。 しかし、サーバー・レベルでサポートされる属性がわずかしかなかった以前のリリースの WebSphere Application Server ではこのデプロイメントが可能であったため、デプロイメント・ツールは最初にドメインで構成されている属性を確認します。 ドメイン内の属性が、以前のリリースでサポートされていた属性と同じである場合、管理コンソールは、アプリケーション・モジュールを複数のセキュリティー・ドメインに渡ってデプロイするかどうかについての確認を要求します。アプリケーションを異なるドメインに渡ってデプロイする絶対的な要件がない限りは、デプロイメントを中止して、同じセキュリティー・ドメイン内のサーバーとクラスターを選択してください。
相互レルム通信
アプリケーションが RMI/IIOP プロトコルを使用して通信し、LTPA が認証メカニズムである場合は、関係するサーバー間で LTPA トークンが受け渡しされます。LTPA トークンには、フロントエンド・アプリケーションにログインしているユーザーの、レルム修飾された uniqueId (accessId とも呼ばれます) が含まれています。ダウンストリーム・サーバーは、このトークンを受信すると、そのトークンを暗号化解除しようとします。2 つのサーバー間で LTPA 鍵が共有されている場合は、暗号化解除が成功し、ユーザーの accessId がトークンから取得されます。アプリケーションが使用する現行レルムを用いて、accessId 内のレルムがチェックされます。レルムが一致すると、LTPA トークンの妥当性検査が成功し、許可の処理が続けられます。 レルムが一致しない場合は、外部のレルムからのユーザーをアプリケーションの現在のレルム内で妥当性検査できないため、トークンの妥当性検査は失敗します。 RMI/IIOP および LTPA 認証メカニズムを使用しており、アプリケーションの相互通信が想定されていない場合は、これ以上のことをする必要はありません。
RMI/IIOP および LTPA トークンを使用している場合に、相互レルム通信を成功させるには、最初に、関係するレルム間にインバウンドおよびアウトバウンド通信のための信頼関係を確立する必要があります。
要求の送信元のサーバーの場合、そのサーバーのレルムは、トークンを送るのに信頼できるレルムを持っている必要があります。 このようなレルムを outboundTrustedRealms と呼びます。要求の受信側のサーバーの場合、そのレルムは、受信できる LTPA トークンの送信元であるレルムを信頼する必要があります。このようなレルムを inboundTrustedRealms と呼びます。
アウトバウンドのトラステッド・レルムは、–communicationType オプションを outbound に設定した addTrustedRealms コマンドを使用して確立できます。このレルムは、管理コンソールの「CSIv2 アウトバウンド通信 (CSIv2 outbound communications)」パネルの「トラステッド認証レルム - アウトバウンド (Trusted authentication realms - outbound)」をクリックしても確立できます。
インバウンドのトラステッド・レルムは、–communicationType オプションを inbound に設定した、同一の addTrustedRealms コマンド・タスクを使用して確立できます。このレルムは、管理コンソールを使用しても確立できます。
このセクション内で後に示す図は、RMI/IIOP を使用して異なるユーザー・レルム (レジストリー) を使用するアプリケーション間の通信を示しています。この例では、アプリケーション app1 (例えば、サーブレット) は、realm1 ユーザー・レジストリーを使用するよう構成されています。app2 アプリケーション (例えば、EJB) は、realm2 ユーザー・レジストリーを使用するよう構成されています。ユーザー user1) は、最初に app1 内のサーブレットにログインし、次に app2 内の EJB にアクセスしようとします。以下を設定する必要があります。
- Domain1 では、realm1 は、アウトバウンド通信のための realm2 を信頼する必要があります。
- Domain2 では、realm2 は、インバウンド通信のための realm1 を信頼する必要があります。
- user1 の accessId を app2 の許可テーブルに構成する必要があります。
app2 は、user1 の accessId を含む LTPA トークンを受信すると、そのトークンを暗号化解除します。どちらのサーバーも同じ LTPA 鍵を共用します。LTPA トークンは、外部レルムがトラステッド・レルムであることを確認して、user1 の accessId に基づき許可を実行します。 セキュリティー属性の伝搬が使用不可になっていなければ、user1 のグループ情報も app2 に伝搬されます。許可テーブルにグループ情報が含まれている場合は、グループを許可検査に使用できます。許可テーブルに個々のユーザーおよびグループを追加する代わりに、特別サブジェクト AllAuthenticatedInTrustedRealms をロールに関連付けることができます。
前の例のアプリケーションがそれぞれ異なるセルにデプロイされている場合は、以下を行う必要があります。
- セル間で LTPA 鍵を共有します。
- wsadmin ユーティリティーを使用して、外部ユーザーとグループの accessId を使用して、app2 の許可テーブルを更新します。管理コンソールには、セルの有効範囲の外部のレルムへのアクセス権限がありません。

レルム間で信頼関係が確立すると、サーバーは、LTPA トークンを受信して、そのトークンを暗号化解除するときに、そのインバウンドのトラステッド・レルム・リストに外部レルムが存在しているかどうかを確認します。その外部レルムを信頼できる場合は、認証は成功します。ただし、そのレルムは外部レルムであるため、ユーザー・レジストリーを検索して、そのユーザーに関する情報を収集することはありません。LTPA トークンにどのような情報が含まれていても、それはユーザーの許可に使用されます。
LTPA トークン内の唯一の情報は、ユーザーの固有 ID です。ユーザーのこの固有 ID は、このアプリケーションの許可テーブルに存在している必要があります。 固有 ID が存在している場合は、許可は成功です。ただし、属性伝搬が使用可能になっている場合は、ユーザーの追加の許可属性 (このユーザーが属しているグループ) が、発信元のサーバーから受信側のサーバーへ送信されます。これらの追加属性は、アクセスの決定を行う場合に使用されます。伝搬トークンにグループ情報が存在している場合、その情報は許可の決定を行うときに使用されます。
前述したように、トラステッド・レルムからのユーザーまたはグループ (あるいはその両方) に関する情報は、受信側のアプリケーションの許可テーブルに存在している必要があります。具体的にいえば、ユーザーまたはグループ (あるいはその両方) の accessId は、アプリケーションのバインディング・ファイルに存在している必要があります。これに該当しなければならないのが、アプリケーションをデプロイするときです。ドメインにアプリケーションをデプロイするときに、管理コンソールで、そのドメインのいずれかのトラステッド・レルムからのユーザーおよびグループの accessId を、許可テーブルに追加できます。
個々のユーザーおよびグループを追加する代わりに、特別サブジェクト AllAuthenticatedInTrustedRealms をロールに関連付けるオプションもあります。このサブジェクトは、現在サポートされている AllAuthenticated 特別サブジェクトに類似しています。違いは、AllAuthenticated 特別サブジェクトは、アプリケーションと同じレルム内のユーザーを参照するのに対し、AllAuthenticatedInTrustedRealms 特別サブジェクトは、トラステッド・レルム内およびアプリケーションのレルム内のすべてのユーザーに適用される、という点です。
$AdminApp インストール・スクリプトを使用することにより、accessId を関連付けることができます。accessId は固有のフォーマットをとるので、displayAccessIds を true に設定したコマンド・タスク listRegistryUsers を使用します。 無効な名前またはフォーマットをこのフィールドに入力した場合、許可は失敗します。
デプロイメント・マネージャーは、すべてのドメイン内のすべてのユーザー・レジストリー構成にアクセスできるため、トラステッド・レルムのユーザーおよびグループ情報は、デプロイメント・マネージャーによって取得されます。ただし、特定の状況下では、ユーザーおよびグループ情報を取得することができません。
例えば、外部ノードでホストされているサーバーが、そのドメインのレジストリーとして localOS を使用している場合、デプロイメント・マネージャーは、同じオペレーティング・システムのセットアップで稼働していない限り、ユーザーおよびグループ情報を取得することができません。この情報を取得するには、外部のオペレーティング・システムに接続する必要があります。これを行うには、そのドメインに関連付けられているサーバー内のレジストリーを直接呼び出します。これが機能するためには、ドメインに関連付けられているサーバーを始動する必要があります。さらに、最上位のセキュリティー・カスタム・プロパティーの、com.ibm.websphere.allowRegistryLookupOnProcess プロパティーを true に設定する必要もあります。このプロパティーが設定されている場合、デプロイメント・マネージャー・コードは、セキュリティー・ドメインに関連付けられているサーバーの 1 つを検索し、そこからユーザーおよびグループ情報を直接取得します。これを可能にするために、サーバーの 1 つにある MBean を呼び出します。
そのドメインを使用しているサーバーのうちのどのサーバーの MBean にもアクセスできない場合は、各ユーザーおよびグループのユーザーおよびグループ accessId 情報を手動で入力できるパネルが、管理コンソールに表示されます。このフィールドには、正しい accessId フォーマットを入力する必要があることが重要です。ユーザーの accessId フォーマットは user:realmName/userUniqueId です。realmName は、ユーザーが存在しているレルムの名前、userUniqueId は、そのユーザーを表す uniqueId ですが、これは使用されているレジストリーによって異なります。
例えば、LDAP の場合、uniqueUserId は識別名 (DN) で、Windows localOS レジストリーの場合は、ユーザーの SID です。UNIX プラットフォームの場合は UID です。カスタム・レジストリーの場合は、実装によります。
同様に、グループの場合、accessId のフォーマットは group:realmName/groupUniqueId です。前述のように、該当するドメインまたはレルムの正しいフォーマットを取得できるようにするために、–displayAccessIds オプションを true に設定して listRegistryUsers および listRegistryGroups コマンドを使用します。
トラステッド・レルムのユーザーおよびグループ、または AllAuthenticatedInTrustedRealms 特殊オブジェクトがアプリケーションの許可テーブルに追加されると、そのアプリケーションは、そのトラステッド・レルムを使用している他のアプリケーションからの要求を受け取る準備が完了します。受信側のサーバー上での LTPA トークンの妥当性検査では、最初に、レルムが信頼できるかが確認されます。次に、許可エンジンが、外部ユーザーまたはグループ、あるいはその両方、または AllAuthenticatedInTrustedRealms 特別サブジェクトに、リソースへのアクセスに必要なロールへのアクセス権限が与えられているかどうかをチェックします。 与えられている場合には、アクセス権限が許可されます。
相互レルム通信は、WebSphere 組み込み許可を使用している場合にのみ適用可能です。SAF for z/OS などの他の許可エンジンを使用している場合は、外部ユーザーをそれ独自のリポジトリー内のユーザーにマップするカスタム・ログイン・モジュールを実装することにより、任意の相互レルム許可を実現できます。
ノードとセキュリティー・ドメインのフェデレート
セキュリティー・ドメインが基本バージョンで構成され、セルにフェデレートされている場合、基本バージョンで構成されたそのセキュリティー・ドメインは、セル内のそのサーバーに合うようにも構成されています。サーバーは、フェデレーションの前後で同じドメイン・セキュリティー構成を使用できます。基本サーバーをセルにフェデレートする場合は、セキュリティー・ドメインに割り当てられたリソースを、セル有効範囲ではなく、サーバー有効範囲にする必要があります。
基本サーバーが管理エージェント・プロセスに登録されていることを想定していて、基本プロファイル内のすべてのサーバーにこのセキュリティー・ドメインを使用させることが目的である場合は、セル有効範囲をリソースとして使用します。
フェデレーション中に基本のセキュリティー・ドメインが既にセル・レベルに存在している場合、addNode コマンドは失敗します。フェデレーション中にセキュリティー・ドメインを組み込まないようにするために、–excludesecuritydomains オプションを使用できます。
フェデレーテッド・ノードをセルから除去する場合は、そのノード内のリソースをセキュリティー・ドメインから除去する必要があります。 セキュリティー・ドメインが、複数のノードにわたるクラスターに関連付けられている場合、それらのノードは除去されません。スクリプト・コマンド、または管理コンソールを使用することにより、セキュリティー・ドメイン、または使用されていないドメインからいつでもリソースを除去できます。
混合バージョン環境でのセキュリティー・ドメイン
すべてのノードを最新バージョンにマイグレーションした場合は、セキュリティー・ドメインを作成する必要があります。セルをドメインに関連付ける必要がある場合には、特にこのことが該当します。ただし、セキュリティー・ドメインを混合バージョン環境に作成する場合は、以下の点に注意してください。
- セル全体のドメインが混合バージョン・セットアップに作成されると、PassThroughToGlobalSecurity と呼ばれるドメインが自動的に作成されます。
セル全体のドメインの作成時に、すべての混合クラスターがこのドメインに割り当てられます。この PassThroughToGlobalSecurity ドメインは、それに属性を追加できず、割り当てることができるのはリソースのみである、という意味で特殊です。
PassThroughToGlobalSecurity ドメインに割り当てられているすべてのリソースは、グローバル・セキュリティー構成情報を使用します。 混合バージョンのセットアップ内のノードが最新バージョンにマイグレーションされると、常にこれらのノード内のサーバーとクラスターがこのドメインに追加されます。これらのノード内のすべてのサーバーとクラスターに含まれるアプリケーションは、セル全体のドメインを使用しません。その代わりに、それらのアプリケーションは、マイグレーションの前後にグローバル・セキュリティー構成を使用します。
これらのサーバーのいずれかが、セル全体のドメインを使用する必要がある場合は、これらのリソースを PassThroughToGlobalSecurity ドメインから除去する必要があります。 マイグレーションされたノードに作成された新しいサーバーとクラスターは、PassThroughToGlobalSecurity ドメインではなく、セル全体のドメインを使用します。 この結果として、サーバーとクラスターが混合し、それらの一部はグローバル・セキュリティーを使用し、一部はセル全体のドメインを使用することになります。
- セル全体のドメインが作成されると、WebSphere Application Server バージョン 9.0 クラスターへの古いバージョンのクラスター・メンバーの追加は制限されます。この追加アクションにより、クラスターが混合クラスターになってしまうためです。 この制限は、WebSphere Application Server バージョン 9.0 クラスターがドメインに関連付けられており、 前のバージョンのクラスター・メンバーがこのクラスターに追加される場合にも該当します。 この制限は、混合クラスターへのセキュリティー・ドメインの関連付けを避けるために必要です。
- 可能であれば、すべてのノードをマイグレーションした後に、セル全体のドメインを作成してください。この場合、セル全体のドメインは、セルの一部にだけではなく、セル全体に適用可能です。 これにより、PassThroughToGlobalSecurity ドメインと、セキュリティー・ドメインを含む混合クラスターのシナリオを作成する必要もなくなります。
セキュリティー・ドメインの変更
セキュリティー・ドメインを変更するには、管理コンソールのタスクまたはスクリプト・コマンドを使用します。 管理タスクおよびスクリプト・コマンドの完全なリストについては、この文書の終わりにある「関連タスク」のリンクを参照してください。
セキュリティー・ドメインが作成され、有効範囲のセットに関連付けられたら、この新規ドメインに関連付けられているサーバーを再始動する必要があります。再始動後に、新規ドメインに関連付けられている有効範囲内のアプリケーションは、ドメインで定義されているセキュリティー属性を使用します。
いずれかのドメイン属性に変更を加えた場合は、その属性に割り当てられているすべての有効範囲を再始動する必要があります。新しい有効範囲が追加された場合にも、その有効範囲を再始動する必要があります。ドメイン構成、すなわちセキュリティー属性または有効範囲のいずれかに変更を加えると、そのドメイン構成を使用しているアプリケーションがその影響を受けます。
既存のドメインに変更を加える前に、以下の潜在的な影響を考慮してください。例えば、ドメインで構成されているユーザー・レジストリーが除去され、サーバーが再始動されると、セル全体のドメインからのユーザー・レジストリー (定義されている場合) またはグローバル・セキュリティー構成が使用されます。これは、アプリケーションの認証および許可に影響する可能性があります。アプリケーションに関連付けられているユーザーとグループは、新しいレジストリーでは有効ではなくなる可能性があります。考慮すべきもう 1 つの例は、JAAS 構成がドメインから除去される場合です。ドメインに依存するアプリケーションは、JAAS 構成を使用できなくなります。セキュリティー構成が変更されると、常にアプリケーションがその影響を受ける可能性があるため、すべてのセキュリティー構成の変更には細心の注意が必要になります。
![[z/OS]](../images/ngzos.gif)
混合リリース環境に必要な、リリースのサポートに必要な PTF
以前のバージョンの WebSphere Application Server for z/OS IIOP クライアントが、複数のセキュリティー・ドメインをホストする WebSphere Application Server バージョン 9.0 for z/OS アプリケーション・サーバーと相互運用している混合リソース環境には、リリースのサポートに必要な PTF が必要です。
バージョン 9.0 よりも前の IIOP クライアントでは、バージョン 9.0 アプリケーション・サーバーのセキュリティー・ドメインにわたって配置される IIOP を実行するために、IIOP 配置処理コードの更新を必要とします。
WebSphere Application Server for z/OS 5.1: W510246
WebSphere Application Server for z/OS v6.0: 602.29
WebSphere Application Server for z/OS v6.1: 610.17
この要件は、複数のセキュリティー・ドメインが構成され、使用可能になっている WebSphere for z/OS アプリケーション・サーバーに対して要求を呼び出す WebSphere for z/OS IIOP クライアントにのみ適用されます。