| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解 11g リリース1(10.3.6) B61618-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解 11g リリース1(10.3.6) B61618-04 |
|
前 |
次 |
この節では、以下のトピックを取り上げます。
セキュリティ・レルムは、WebLogicリソースを保護する複数のメカニズムで構成されています。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます(図4-1を参照)。ユーザーはセキュリティ・レルムで定義されていないと、そのセキュリティ・レルムに属するWebLogicリソースにアクセスできません。ユーザーが特定のWebLogicリソースにアクセスしようとした場合、WebLogic Serverは、関連するセキュリティ・レルムでそのユーザーに割り当てられているセキュリティ・ロールと、その特定のWebLogicリソースのセキュリティ・ポリシーをチェックして、ユーザーを認証および認可します。
ユーザーとは、myrealmなどの、セキュリティ・レルムで認証できるエンティティのことです(図4-1を参照)。ユーザーは、アプリケーション・エンド・ユーザーなどの人物でも、クライアント・アプリケーションやその他のWebLogic Serverインスタンスなどのソフトウェア・エンティティでもかまいません。認証の結果として、ユーザーにはIDつまりプリンシパルが割り当てられます。各ユーザーに、セキュリティ・レルムの中において一意のIDが与えられます。ユーザーはセキュリティ・ロールと関連付けられているグループに入れるか、またはセキュリティ・ロールと直に関連付けることができます。
ユーザーがWebLogic Serverにアクセスしようとする場合、ユーザーは、JAAS LoginModuleを通じて証明データ(たとえば、パスワードまたはデジタル証明書)をセキュリティ・レルム内に構成されている認証プロバイダに提示します。WebLogic Serverがユーザー名と資格証明に基づいてユーザーのIDを確認できた場合、WebLogic Serverはユーザーのかわりにコードを実行するスレッドをそのユーザーに割り当てられたプリンシパルに関連付けます。ただし、スレッドがコードの実行を始める前に、WebLogic ServerはWebLogicリソースのセキュリティ・ポリシーとユーザーに割り当てられているプリンシパルをチェックして、ユーザーが処理を続行するために必要な許可を持っていることを確認します。
WebLogic認証プロバイダを使用し、ユーザーを定義する場合は、そのユーザーのパスワードも定義します。WebLogic Serverでは、すべてのパスワードがハッシュ化されています。その後、クライアントのリクエストを受け取ると、WebLogic Serverはクライアントが提示するパスワードをハッシュ化して、ハッシュ化済みパスワードと一致するかどうか比較します。
|
注意: すべてのユーザー名とグループはセキュリティ・レルム内で一意でなければなりません。 |
グループとは、論理的に順序付けされたユーザーの集合のことです(図4-1を参照)。一般に、グループ・メンバーどうしは何らかの共通点を持っています。たとえば、企業の販売スタッフを、販売員と販売マネージャという2つのグループに分けることができます。このように分けることで、職務によって販売スタッフのWebLogicリソースへのアクセス・レベルを異なるものにできます。
グループを管理する方が、多くのユーザーを個々に管理するよりも効率的です。たとえば、管理者はユーザーをグループに所属させ、グループにセキュリティ・ロールを割り当ててから、そのセキュリティ・ロールをセキュリティ・ポリシーを介してWebLogicリソースに関連付けることで、50ユーザーの許可を一度に指定できます。
すべてのユーザー名とグループはセキュリティ・レルム内で一意でなければなりません。
セキュリティ・ロールとは、特定の条件に基づいてユーザーまたはグループに付与される権限のことです(図4-1を参照)。グループと同様、セキュリティ・ロールを使用すると、複数のユーザーによるWebLogicリソースへのアクセスを一度に制限できます。ただし、グループとは異なり、セキュリティ・ロールには以下のような特徴があります。
ユーザー名、グループ・メンバーシップ、または時刻などの条件に基づいて動的に計算されてユーザーまたはグループに付与されます。
常にWebLogic Serverドメイン全体を対象とするグループとは異なり、WebLogic Serverドメインの単一のアプリケーションに属する特定のWebLogicリソースを対象にできます。
セキュリティ・ロールをユーザーまたはグループに付与すると、付与されている間に限り、定義されたアクセス権限がそのユーザーまたはグループに与えられます。複数のユーザーまたはグループに単一のセキュリティ・ロールを付与することができます。
|
注意: WebLogic Server 6.xでは、セキュリティ・ロールはWebアプリケーションとEnterprise JavaBeans (EJB)のみに適用されました。以降のリリースでは、セキュリティ・ロールは、定義されているすべてのWebLogicリソースに対して適用されます。 |
セキュリティ・ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間の関連付けです。セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護します。WebLogicリソースは、セキュリティ・ポリシーを作成するまでは保護されません。ポリシー条件とは、セキュリティ・ポリシーを作成する際の条件です。WebLogic Serverによってデフォルトのポリシー条件セットが提供されます。WebLogic Serverには、HTTPサーブレット・リクエストとセッションの属性およびEJBメソッド・パラメータにアクセスするポリシー条件が含まれます。「ポリシー・エディタ」には「時間」と「日付」のポリシーが含まれます。
|
注意: セキュリティ・ポリシーは、WebLogic Server 6.xでWebLogicリソースを保護するために使用していたアクセス制御リスト(ACL)にかわるものです。 |
セキュリティ・プロバイダとは、WebLogicリソースを保護するためにアプリケーションにセキュリティ・サービスを提供するモジュールのことです(図4-1を参照)。WebLogic Server製品の一部として提供されるセキュリティ・プロバイダを使用することも、サード・パーティ・セキュリティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することも、独自にカスタム・セキュリティ・プロバイダを開発することもできます。カスタム・セキュリティ・プロバイダの開発方法については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
この節では、以下の内容について説明します。
以下の節では、セキュリティ・プロバイダ・データベースとは何か、セキュリティ・レルムがセキュリティ・プロバイダ・データベースの使用にどのように影響するのかについて説明します。
セキュリティ・プロバイダ・データベースには、一部のセキュリティ・プロバイダがセキュリティ・サービスを提供するために使用するユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明が格納されます(図4-1を参照)。たとえば、認証プロバイダではユーザーとグループについての情報、認可プロバイダではセキュリティ・ポリシーについての情報、ロール・マッピング・プロバイダではセキュリティ・ロールについての情報、資格証明マッピング・プロバイダではリモート・アプリケーションに対して使用する資格証明についての情報が必要になります。これらのセキュリティ・プロバイダが正しく機能するためには、この情報をデータベースでアクセスできるようにする必要があります。
セキュリティ・プロバイダ・データベースとしては、WebLogicセキュリティ・プロバイダで使用されるような組込みLDAPサーバー、Web上で使用できるサンプル・カスタム・セキュリティ・プロバイダで使用されるようなプロパティ・ファイル、またはすでに使用している、顧客側で用意された製品レベルの品質のデータベースを使用できます。
|
注意: サンプル・カスタム・セキュリティ・プロバイダは、Oracle Technology Network (OTN)のhttps://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S224で入手できます。 |
セキュリティ・プロバイダ・データベースは、セキュリティ・プロバイダが最初に使用されるときに初期化する必要があります。(つまりセキュリティ・プロバイダを含むセキュリティ・レルムがデフォルトの(アクティブな)セキュリティ・レルムとして設定される前に)初期化は次の場合に実行できます。
WebLogic Serverのインスタンスが起動するとき。
セキュリティ・プロバイダのMBeanの1つが呼び出されるとき。
セキュリティ・プロバイダ・データベースは、少なくとも、WebLogic Serverで提供されるデフォルトのグループ、セキュリティ・ポリシー、セキュリティ・ロールで初期化されます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「セキュリティ・プロバイダとWebLogicリソース」を参照してください。
同じセキュリティ・レルムで同じタイプの複数のセキュリティ・プロバイダが構成されている場合、それらのセキュリティ・プロバイダでは同じセキュリティ・プロバイダ・データベースを使用できます。この動作は、すべてのWebLogicセキュリティ・プロバイダおよびサンプル・セキュリティ・プロバイダ(Oracle Technology Network (OTN)のhttps://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S224で入手可能)で同じように機能します。
たとえば、デフォルト・セキュリティ・レルム(myrealm)で2つのWebLogic認証プロバイダを構成する場合、それらのWebLogic認証プロバイダは両方とも組込みLDAPサーバーの同じ位置をセキュリティ・プロバイダ・データベースとして使用し、したがって同じユーザーとグループを使用します。さらに、WebLogic認証プロバイダの1つにユーザーまたはグループを追加すると、他のWebLogic認証プロバイダでもそのユーザーまたはグループが表示されます。
|
注意: 同じタイプの2つのWebLogicセキュリティ・プロバイダ(またはサンプル・セキュリティ・プロバイダ)が2つの異なるセキュリティ・レルムで構成されている場合は、それぞれが独自のセキュリティ・プロバイダ・データベースを使用します。一度にアクティブにできるのは、1つのセキュリティ・レルムだけです。 |
独自に開発したカスタム・セキュリティ・プロバイダ(またはサード・パーティ・セキュリティ・ベンダーのカスタム・セキュリティ・プロバイダ)は、セキュリティ・プロバイダの各インスタンスが独自のデータベースを使用するように、またはセキュリティ・レルムのすべてのセキュリティ・プロバイダ・インスタンスが同じデータベースを共有するように設計できます。これは、既存のシステムとセキュリティ要件に基づいて決断する必要のある設計上の決定事項です。セキュリティ・プロバイダに関する設計上の決定事項の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「設計上の考慮事項」を参照してください。
WebLogic Serverでは、組込みLDAPサーバーが、WebLogicセキュリティ・プロバイダ用のユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーを格納するデータベースとして使用されます。組込みLDAPサーバーは、適度に小規模な環境(ユーザー数10,000以下)向けの、製品レベルの品質を持つ完全なLDAPサーバーです。この推奨値より大きい規模にする必要のあるアプリケーションでは、組込みLDAPサーバーは、将来的に本番デプロイメント用の外部LDAPサーバーにエクスポートする際の、優秀な開発、統合およびテスト環境として使用できます。組込みLDAPサーバーでは、以下のアクセスおよび格納機能がサポートされています。
LDAPサーバー内のエントリへのアクセスとエントリの変更
LDAPブラウザを使用した、LDAPサーバーに対するセキュリティ・データのインポートとエクスポート
WebLogicセキュリティ・プロバイダによる読込みおよび書込みアクセス
|
注意: WebLogic Serverでは、組込みLDAPサーバーへの属性の追加はサポートされていません。 |
表4-1に、各WebLogicセキュリティ・プロバイダによる組込みLDAPサーバーの使用方法を示します。
表4-1 組込みLDAPサーバーの使用方法
| WebLogicセキュリティ・プロバイダ | 組込みLDAPサーバーの使用 |
|---|---|
|
認証 |
ユーザーおよびグループ情報を格納します。 |
|
IDアサーション |
ユーザーおよびグループ情報を格納します。 |
|
認可 |
セキュリティ・ロールおよびセキュリティ・ポリシーを格納します。 |
|
裁決 |
なし。 |
|
ロール・マッピング |
指定されたWebLogicリソースについてリクエスト側に付与されるロール群を計算によって取得することで、動的ロール関連付けをサポートします。 |
|
監査 |
なし。 |
|
資格証明マッピング |
ユーザー名/パスワードの資格証明マッピング情報を格納します。 |
|
証明書レジストリ |
登録されている目的の証明書を格納します。 |
WebLogic Serverでは、外部RDBMSを以下のセキュリティ・プロバイダが使用するデータ・ストアとして使用することができます。
XACML認証プロバイダおよびロール・マッピング・プロバイダ
WebLogic資格証明マッピング・プロバイダ
PKI資格証明マッピング・プロバイダ
SAML 1.1の以下のプロバイダ
SAML IDアサーション・プロバイダV2
SAML資格証明マッピング・プロバイダV2
SAML 2.0の以下のプロバイダ
SAML 2.0 IDアサーション・プロバイダ
SAML 2.0資格証明マッピング・プロバイダ
デフォルトの証明書レジストリ
RDBMSセキュリティ・ストアがセキュリティ・レルム内で構成されているとき、セキュリティ・レルムに作成済みの任意の先行セキュリティ・プロバイダのインスタンスは、データストアとして、組込みLDAPサーバーではなく、RDBMSセキュリティ・ストアのみを自動的に使用します。その他のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します; たとえば、WebLogic認証プロバイダは組込みLDAPサーバーを使用します。
RDBMSセキュリティ・ストアはドメインの作成時に構成することをお薦めします。このプロセスを簡素化するように構成ウィザードが改良されました。これにより、ドメインの起動時にドメインへのアクセスに必要なセキュリティ・ポリシーが外部RDBMSから確実に取得されるようになります。
RDBMSセキュリティ・ストアは、クラスタ環境のようにドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを使用する場合に必要になります。RDBMSセキュリティ・ストアについては、『Oracle WebLogic Serverの保護』の「RDBMSセキュリティ・ストアの管理」を参照してください。
以下の節では、WebLogic Serverで使用できるセキュリティ・プロバイダのタイプを説明します。
|
注意: 複数のタイプのプロバイダを結合した単一のセキュリティ・プロバイダを開発することはできません。たとえば、認可とロール・マッピングを行う1つのセキュリティ・プロバイダを開発することはできません。 |
認証プロバイダを使用すると、WebLogic Serverではユーザーを検証することで信頼を確立できます。WebLogic Serverのセキュリティ・アーキテクチャは、ユーザー名とパスワードの認証、証明書とダイジェストの認証(WebLogic Serverを直接用いる)、およびHTTP証明書に基づく認証(外部のWebサーバーを介して行う)を実行する認証プロバイダをサポートします。
|
注意: IDアサーション・プロバイダは、境界に基づく認証と複数のセキュリティ・トークン・タイプ/プロトコルを処理する特殊なタイプの認証プロバイダです。 |
認証プロバイダには、ユーザーまたはシステムの認証を実際に実行するLoginModuleが組み込まれています。認証プロバイダは、プリンシパル(ユーザー/グループ)に対する署名と信頼性の確認によって追加のセキュリティを提供するプリンシパル検証プロバイダも使用します。プリンシパル検証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
セキュリティ・レルムには少なくとも1つの認証プロバイダが必要です。1つのセキュリティ・レルムに複数の認証プロバイダを構成することもできます。複数の認証プロバイダを構成すると、それぞれが異なる認証を実行する複数のLoginModuleを使用できます。管理者は、各認証プロバイダを構成して、ユーザーがシステムにログインするときに複数のLoginModuleがどのように呼び出されるのかを指定します。認証プロバイダは認証で使用されるプリンシパルにセキュリティを追加するので、プリンシパル検証プロバイダは認証プロバイダからアクセス可能である必要があります。
認証プロバイダとLoginModuleの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「認証プロバイダ」を参照してください。
IDアサーションでは、リクエストの外部に存在することのある、クライアントから提供されるトークンを使用してクライアントのIDが確立されます。したがって、IDアサーション・プロバイダの機能は、トークンを検証してユーザー名にマップすることです。このマッピングがいったん完了すれば、認証プロバイダのLoginModuleを使用してユーザー名がプリンシパルに変換されます。IDアサーション・プロバイダを使用して、WebLogic Serverではユーザーを検証して信頼を確立できます。
IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する特殊な形態(つまり境界認証)の認証プロバイダです。IDアサーション・プロバイダ用のLoginModuleを作成すれば、認証プロバイダのかわりにIDアサーション・プロバイダを使用できます。また、認証プロバイダのLoginModuleを使用する場合は、認証プロバイダに加えてIDアサーション・プロバイダも使用できます。IDアサーション・プロバイダは境界認証を有効にし、シングル・サインオンをサポートします。
WebLogic ServerのIDアサーション・プロバイダは、境界に基づく認証(Webサーバー、ファイアウォール、VPN)を実行し、複数のトークン・タイプ(ダイジェスト、SPNEGO、SAML 1.1および2.0など)をサポートし、複数のセキュリティ・プロトコル(Kerberos、SOAP、IIOP-CSIv2)を処理できます。Microsoft Passportなどの様々なトークン・タイプをサポートするカスタムIDアサーション・プロバイダを記述することもできます。認証プロバイダのLoginModuleと一緒に使用すると、IDアサーション・プロバイダはシングル・サインオンをサポートします。たとえば、IDアサーション・プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザーは何度もサインオンを求められることはありません。
|
注意: X.501およびX.509証明書に対してWebLogic IDアサーション・プロバイダを使用するには、WebLogic Server製品に付属のデフォルトのユーザー名マッパー(weblogic.security.providers.authentication. DefaultUserNameMapperImpl)を使用するか、独自のweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を使用するかのいずれかの方法があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタムIDアサーション・プロバイダを開発する必要があるか」を参照してください。 |
セキュリティ・レルムでは複数のIDアサーション・プロバイダを構成できますが、必須ではありません。IDアサーション・プロバイダでは複数のトークン・タイプをサポートできますが、一度にアクティブになるのは特定のIDアサーション・プロバイダごとに1つのトークン・タイプだけです。たとえば、特定のIDアサーション・プロバイダはX.2.0とSAML (1.1または2.0。両方は指定できません)の両方をサポートできますが、システムを構成する管理者はIDアサーション・プロバイダでどちらのトークン・タイプ(X.509またはSAML)がアクティブになるのかを選択する必要があります。構成されているIDアサーション・プロバイダが1つしかなく、X.509トークンを処理するように設定されているが、SAMLトークン・タイプもサポートする必要がある場合は、SAMLを処理できるIDアサーション・プロバイダをもう1つ構成し、そのアクティブ・トークン・タイプとしてSAMLを設定する必要があります。
|
注意: WebLogic Serverでは、SAML 1.1用とSAML 2.0用に別々のIDアサーション・プロバイダが用意されています。それらのプロバイダのそれぞれのSAMLバージョンを入れ替えることはできません。SAML IDアサーション・プロバイダV2はSAML 1.1アサーションのみを消費し、SAML 2.0 IDアサーション・プロバイダはSAML 2.0アサーションのみを消費します。 |
IDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「IDアサーション・プロバイダ」を参照してください。
プリンシパル検証プロバイダは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ・プロバイダです。一部のLoginModuleはRMIクライアントのかわりにリモートで実行することができ、プログラムによるサーバー呼出しから次のサーバー呼び出しまでの間、認証済みのサブジェクトがクライアント・アプリケーション・コードに保持できるので、認証プロバイダはプリンシパル検証プロバイダを利用してそのサブジェクト内に格納されているプリンシパルのセキュリティを保護する追加対策を講じます。
プリンシパル検証プロバイダは、プリンシパルに対する署名と信頼性の確認によってそのようなセキュリティを保護する追加対策を講じます。このプリンシパル検証によって、信頼度は向上し、悪意あるプリンシパルによる改ざんの可能性が低下します。サブジェクトのプリンシパルの検証は、WebLogic Serverで各呼出しのRMIクライアント・リクエストがデマーシャリングされる際に行われます。サブジェクトのプリンシパルの信頼性も、認可判定の際に検証されます。
セキュリティ・レルムには少なくとも1つの認証プロバイダが必要なので、セキュリティ・レルムにはプリンシパル検証プロバイダも1つ必要です。複数の認証プロバイダがある場合は、それぞれに対応するプリンシパル検証プロバイダが必要です。
|
注意: WebLogic Server管理コンソールを使用して、プリンシパル検証プロバイダを直接構成することはできません。WebLogic Serverによって認証プロバイダの構成時に、必要なプリンシパル検証プロバイダが構成されます。 |
プリンシパル検証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
認可プロバイダは、ユーザーまたはグループに付与されたセキュリティ・ロールと、要求されたWebLogicリソースに割り当てられたセキュリティ・ポリシーに基づいてWebLogicリソースへのアクセスを制御します。WebLogicリソース、セキュリティ・ロール、およびセキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 を参照してください。
認可プロバイダの中には、アクセス決定があります。アクセス決定は、WebLogicリソースに対して特定の操作を実行する権限がサブジェクトにあるかどうかを実際に判断します。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
セキュリティ・レルムには少なくとも1つの認可プロバイダが必要であり、セキュリティ・レルムで複数の認可プロバイダを構成することもできます。複数の認可プロバイダを構成すると、より高度なモジュール設計に従うことができます。たとえば、WebアプリケーションおよびEnterprise JavaBean (EJB)の権限を処理する1つの認可プロバイダを持ち、その他の種類のWebLogicリソースの権限を処理するもう1つのプロバイダを持つことが可能です。別の例としては、1つの認可プロバイダが国内の従業員を処理し、もう1つのプロバイダは海外の従業員の権限を処理できます。
WebLogic Serverには、以下に示すバルク・アクセス・バージョンの認可プロバイダSSPIインタフェースがあります。
BulkAuthorizationProvider
BulkAccessDecision
バルク・アクセスSSPIインタフェースを使用すると、認可プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
認可プロバイダとアクセス決定の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「認可プロバイダ」を参照してください。
認可プロバイダの一部として、アクセス決定は特定のWebLogicリソースにアクセスするための許可がサブジェクトにあるかどうかを判断します。したがって、複数の認可プロバイダが構成されている場合は、「アクセス可能か」の問いに対してそれぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAINのいずれかです。複数の認可プロバイダのアクセス決定の回答が一致しない場合にどうするかを決定するのは、裁決プロバイダの主な役割です。裁決プロバイダは、各アクセス決定の回答を比較検討し最終結果を返すことで認可上の競合を解消します。認可プロバイダが1つのみ、裁決プロバイダがない場合、その1つの認可プロバイダのアクセス決定から返されるABSTAINはDENYのように処理されます。
|
注意: WebLogic裁決プロバイダでは、WebLogic Server管理コンソールを使用して、決定の放棄を許可または拒否のいずれとして処理するかを制御できます。 |
裁決プロバイダは、構成されている認可プロバイダが複数の場合のみセキュリティ・レルムで構成する必要があります。セキュリティ・レルムで構成できる裁決プロバイダは1つだけです。
|
注意: デフォルトのセキュリティ・レルムには認可プロバイダが1つしかないので、裁決プロバイダが提供されていても必要ありません。ただし、互換性レルムには認可プロバイダが2つあるので、そのレルムでは裁決プロバイダが必要です。 |
WebLogic Serverには、以下に示すバルク・アクセス・バージョンの裁決プロバイダSSPIインタフェースがあります。
BulkAdjudicationProvider
BulkAdjudicator
バルク・アクセスSSPIインタフェースを使用すると、裁決プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
裁決プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「裁決プロバイダ」を参照してください。
ロール・マッピング・プロバイダでは、指定されたWebLogicリソースについてリクエスト側に付与されるセキュリティ・ロール群を計算によって取得することで、動的ロール関連付けをサポートします。WebLogic Securityフレームワークは、特定のWebLogicリソースにアクセスする必要があるときに特定のサブジェクトにどのセキュリティ・ロールが適用されるのかを以下のようにして判断します。
Java EEおよびWebLogicデプロイメント記述子ファイルからセキュリティ・ロールを取得する
ビジネス・ロジックおよび現在の操作パラメータを使用してセキュリティ・ロールを判断する
ロール・マッピング・プロバイダから認可プロバイダにこのセキュリティ・ロール情報が提供されるので、認可プロバイダは、ロール・ベースのセキュリティを用いるWebLogicリソース(すなわち、WebアプリケーションやEnterprise JavaBeansコンテナのリソース)に「アクセスできるか」という質問に答えることができます。
セキュリティ・ロールはJava EEデプロイメント記述子に設定するか、WebLogic Server管理コンソールを使って作成します。デプロイメント記述子に設定されたセキュリティ・ロールはデプロイ時に適用されます(デプロイメント記述子を無視することにした場合を除く)。
セキュリティ・レルムには少なくとも1つのロール・マッピング・プロバイダが必要であり、セキュリティ・レルムで複数のロール・マッピング・プロバイダを構成することもできます。複数のロール・マッピング・プロバイダを構成すると、従来のインフラストラクチャ要件の範囲内で作業することも(たとえばユーザーおよびセキュリティ・ロールの情報が含まれる各LDAPサーバーにつき1つのロール・マッピング・プロバイダを構成する)、または高度なモジュール設計に従うこともできます(たとえばWebアプリケーションおよびEnterprise JavaBeans (EJB)のマッピングを処理するロール・マッピング・プロバイダと、他のタイプのWebLogicリソースのマッピングを処理する別のロール・マッピング・プロバイダを構成する)。
|
注意: 複数のロール・マッピング・プロバイダが構成されている場合には、WebLogic Securityフレームワークは、そのすべてのロール・マッピング・プロバイダから返されるセキュリティ・ロール群の論理積を取ります。つまり、すべてのロール・マッピング・プロバイダからのセキュリティ・ロール名が、重複を削除して1つのリストに結合されます。 |
WebLogic Serverには、以下に示すバルク・アクセス・バージョンのロール・マッピング・プロバイダSSPIインタフェースがあります。
BulkRoleProvider
BulkRoleMapper
バルク・アクセスSSPIインタフェースを使用すると、ロール・マッピング・プロバイダにおいて、1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
ロール・マッピング・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「ロール・マッピング・プロバイダ」を参照してください。
監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布します。監査プロバイダは、特定の監査基準(重大度など)に基づいて特定のイベントを監査するかどうかを決定します。また、監査プロバイダはLDAPディレクトリ、データベース、シンプル・ファイルなどの出力リポジトリに監査情報を書き込むことができます。セキュリティ担当者の呼び出しなどの特定のアクションも監査プロバイダの一部として構成することができます。
他のタイプのセキュリティ・プロバイダ(認証や認可など)は、WebLogic Securityフレームワークを介して呼出しを行うことによって、セキュリティ操作の実行前と実行後に監査サービスをリクエストできます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタム・セキュリティ・プロバイダからのイベントの監査」を参照してください。
監査プロバイダはセキュリティ・レルムで複数を構成できますが、必須ではありません。
監査プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「監査プロバイダ」を参照してください。
資格証明マップは、WebLogic Serverで使用される資格証明から、レガシー・システムまたはリモート・システムで使用される資格証明へのマッピングであり、そのシステムの特定のリソースへの接続方法をWebLogic Serverに指示します。つまり、資格証明マップを使用することで、WebLogic Serverが、認証済みのサブジェクトにかわってリモート・システムにログインできるようになります。
資格証明マッピング・プロバイダでは、ユーザー名とパスワードの組合せ、SAMLアサーション、公開鍵証明書、別名と資格証明タイプの組合せといった複数種の資格証明を処理できます。資格証明マッピングはデプロイメント記述子で設定しても、WebLogic Server管理コンソールを使用して設定してもかまいません。これらの資格証明マッピングはデプロイ時に適用されます(それらの資格証明マッピングを無視することにした場合を除く)。
セキュリティ・レルムには少なくとも1つの資格証明マッピング・プロバイダが必要であり、セキュリティ・レルムで複数の資格証明マッピング・プロバイダを構成することもできます。複数の資格証明マッピング・プロバイダが構成されている場合、WebLogic Securityフレームワークは各資格証明マッピング・プロバイダを巡回して、コンテナでリクエストされている種類の資格証明が含まれているかどうかを検索します。その後、WebLogic Securityフレームワークはすべての資格証明を蓄積してから、リストとして返します。
|
注意: WebLogic Serverでは、SAML 1.1用とSAML 2.0用に別々の資格証明マッピング・プロバイダが用意されています。それらのプロバイダのそれぞれのSAMLバージョンを入れ替えることはできません。SAML資格証明マッピング・プロバイダV2はSAML 1.1アサーションのみを生成し、SAML 2.0 ID資格証明マッピング・プロバイダはSAML 2.0アサーションのみを生成します。 |
資格証明マッピング・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「資格証明マッピング・プロバイダ」を参照してください。
証明書の検索と検証のプロバイダは、証明書のパスを完了させ、X509証明書チェーンを検証します。CLVプロバイダには、2つのタイプがあります。
証明書パス・ビルダー - Webサービスまたはアプリケーション・コードから、証明書、証明書チェーン、または証明書への参照(チェーン内の目的の証明書、または証明書のサブジェクトDN)を受け取ります。このプロバイダが、チェーン内の証明書を検索および検証します。
証明書パス検証プロバイダ - SSLプロトコル、Webサービス、またはアプリケーション・コードから証明書チェーンを受け取り、追加の検証(失効チェックなど)を実行します。
証明書パス・ビルダーと証明書パス検証プロバイダは、セキュリティ・レルムに少なくとも1つずつ構成する必要があります。1つのセキュリティ・レルムに、複数の証明書パス検証プロバイダを構成することもできます。複数のプロバイダを構成した場合は、すべての証明書パス検証プロバイダの検証が正常に終了しないと、証明書または証明書チェーンは有効になりません。
WebLogic Serverでは、CLVプロバイダの機能をWebLogic証明書パス・プロバイダと証明書レジストリで提供します。
キーストアを使用すると、パスワードで保護された、秘密鍵(および秘密鍵に関連付けられた公開鍵証明書)と信頼性のある認証局のストアを作成および管理できます。
WebLogic Server製品の一部として含まれるWebLogicキーストア・プロバイダは、保護された秘密鍵をキーストアから取得するために使用されます。
|
注意: WebLogicキーストア・プロバイダはこのリリースのWebLogic Serverでは非推奨となっていますが、引続きサポートされています。カスタム・キーストア・プロバイダの開発はサポートされていません。かわりに、WebLogicのIDキーストアと信頼キーストア、またはJavaキーストア(JKS)を使用してください。WebLogicキーストア・プロバイダによってサポートされていたすべての機能は、これらのキーストアを使用することで利用できます。WebLogicキーストア・プロバイダは、下位互換性を保持するためにのみサポートされています。WebLogicキーストア・プロバイダは、WebLogic Server 7.0構成と下位互換性を保持する必要がある場合にのみ使用することをお薦めします。 |
レルム・アダプタ・プロバイダは、既存のバージョン6.xセキュリティ・レルムをWebLogic Serverのこのリリースのセキュリティ機能と併用できるようにすることで、バージョン6.x WebLogicセキュリティ・レルムとの下位互換性を提供するものです。レルム・アダプタ・プロバイダは、WebLogic Server 6.xで使用されるレルムAPI (weblogic.security.acl)をWebLogic Serverのこのリリースで使用されるAPIにマップします。図4-2に互換性レルムとサポートされるセキュリティ・プロバイダのタイプを示します。
表4-2に、1つのセキュリティ・レルムで同じタイプの複数のセキュリティ・プロバイダを構成できるかどうかを示します。
表4-2 同一のセキュリティ・レルムにおける同じタイプの複数のセキュリティ・プロバイダ
| タイプ | 複数のプロバイダがサポートされているか |
|---|---|
|
認証プロバイダ |
はい |
|
IDアサーション・プロバイダ |
はい |
|
プリンシパル検証プロバイダ |
はい |
|
認可プロバイダ |
はい |
|
裁決プロバイダ |
いいえ |
|
ロール・マッピング・プロバイダ |
はい |
|
監査プロバイダ |
はい |
|
資格証明マッピング・プロバイダ |
はい |
|
証明書の検索と検証のプロバイダ |
1つの証明書パス・ビルダー 複数の証明書パス検証プロバイダ |
|
キーストア・プロバイダ |
はい |
|
レルム・アダプタ・プロバイダ |
はい(裁決プロバイダを除く、サポートされているすべてのレルム・アダプタ・プロバイダのタイプ)。サポートされるタイプについては、図4-2を参照してください。 |
すべてのセキュリティ・プロバイダは、セキュリティ・レルムのコンテキスト内に存在します。以前のWebLogic Serverリリース6.xを使用しているのでなければ、デフォルト・レルム (つまりmyrealmと呼ばれるアクティブなセキュリティ・レルム)としてあらかじめ定義されているWebLogic Serverセキュリティ・レルムには図4-3に示すWebLogicセキュリティ・プロバイダが用意されています。
|
注意: リリース6.xからこのリリースへアップグレードしている場合には、最初にあらかじめ用意されているものは互換性レルム(最初はデフォルト・レルムとして定義されている)で、それを使用すれば既存の構成をそのまま扱うことができます。ただし、6.xモデルは非推奨になっているので、セキュリティ・レルムをこのリリースのWebLogic Serverで使用可能なセキュリティ・モデルにアップグレードする必要があります。 |
セキュリティ・プロバイダはWebLogic Serverセキュリティ・レルムに「プラグイン」される個別のモジュールまたはコンポーネントなので、手間をかけずに追加、置換、または削除できます。WebLogicセキュリティ・プロバイダ、独自に開発したカスタム・セキュリティ・プロバイダ、サード・パーティ・セキュリティ・ベンダーのセキュリティ・プロバイダ、または以上3つの組合せを使用して完全に機能するセキュリティ・レルムを作成できます。ただし、図4-3にも示すように、一部のタイプのセキュリティ・プロバイダはセキュリティ・レルムが正しく機能する上で必須の要素です。表4-1は、セキュリティ・レルムが完全に機能するためにどのセキュリティ・プロバイダを構成しなければならないかを説明しています。
表4-3 セキュリティ・レルムのセキュリティ・プロバイダ
| タイプ | 必須? |
|---|---|
|
認証プロバイダ |
はい |
|
IDアサーション・プロバイダ |
境界認証を使用する場合は「はい」 |
|
プリンシパル検証プロバイダ |
はい |
|
認可プロバイダ |
はい |
|
裁決プロバイダ |
複数の認可プロバイダが構成されている場合は「はい」 |
|
ロール・マッピング・プロバイダ |
はい |
|
監査プロバイダ |
いいえ |
|
資格証明マッピング・プロバイダ |
はい |
|
証明書の検索と検証のプロバイダ |
はい |
|
キーストア・プロバイダ |
いいえ 注意: WebLogicキーストア・プロバイダはこのリリースのWebLogic Serverでは非推奨となっていますが、引き続きサポートされています。カスタム・キーストア・プロバイダの開発はサポートされていません。かわりにJavaキーストア(JKS)を使用してください。WebLogicキーストア・プロバイダは、WebLogic Server 7.0構成と下位互換性を保持する必要がある場合にのみ使用することをお薦めします。Javaキーストアの使い方については、『Oracle WebLogic Serverの保護』の「本番用のキーストアの構成」を参照してください。 |
セキュリティ・レルムの詳細は、『Oracle WebLogic Serverの保護』の「WebLogicセキュリティの構成: 主な手順」を参照してください。
