|
|
セキュリティ レルムは、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 6.x では、セキュリティ ロールは Web アプリケーションとエンタープライズ JavaBean (EJB) だけに適用されました。このリリースの WebLogic Server では、セキュリティ ロールは、定義されているすべての WebLogic リソースに対して適用されます。 |
セキュリティ ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールとの間の関連付けです。セキュリティ ポリシーは、権限のないアクセスから WebLogic リソースを保護します。WebLogic リソースは、セキュリティ ポリシーを作成するまでは保護されません。ポリシー条件とは、セキュリティ ポリシーを作成する際の条件です。WebLogic Server にはデフォルトのポリシー条件のセットがあり、HTTP サーブレット リクエスト属性、HTTP セッション属性、および EJB メソッド パラメータにアクセスするポリシー条件が含まれています。[ポリシー エディタ] には [時間] と [日付] のポリシーが含まれます。
| 注意 : | セキュリティ ポリシーは、WebLogic Server 6.x で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) に代わるものです。 |
セキュリティ プロバイダとは、WebLogic リソースを保護するためにアプリケーションにセキュリティ サービスを提供するモジュールのことです (図 4-1 を参照)。WebLogic Server 製品の一部として提供されるセキュリティ プロバイダを使用することも、サード パーティ セキュリティ ベンダからカスタム セキュリティ プロバイダを購入することも、独自にカスタム セキュリティ プロバイダを開発することもできます。カスタム セキュリティ プロバイダの開発方法については、『WebLogic セキュリティ プロバイダの開発』を参照してください。
以下の節では、セキュリティ プロバイダ データベースとは何か、セキュリティ レルムがセキュリティ プロバイダ データベースの使用にどのように影響するのかについて説明します。
セキュリティ プロバイダ データベースには、一部のセキュリティ プロバイダがセキュリティ サービスを提供するために使用するユーザ、グループ、セキュリティ ポリシー、セキュリティ ロール、および資格が格納されます (図 4-1 を参照)。たとえば、認証プロバイダではユーザとグループについての情報、認可プロバイダではセキュリティ ポリシーについての情報、ロール マッピング プロバイダではセキュリティ ロールについての情報、資格マッピング プロバイダではリモート アプリケーションに対して使用する資格についての情報が必要になります。これらのセキュリティ プロバイダが正しく機能するためには、この情報をデータベースでアクセスできるようにする必要があります。
セキュリティ プロバイダ データベースとしては、WebLogic セキュリティ プロバイダで使用されるような組み込み LDAP サーバ、Web 上で使用できるサンプル カスタム セキュリティ プロバイダで使用されるような properties ファイル、またはすでに使用しているプロダクション レベルの顧客側で用意されたデータベースを使用できます。
| 注意 : | サンプル カスタム セキュリティ プロバイダは、Oracle Technology Network (OTN) の http://www.oracle.com/technology/community/welcome-bea/index.html で入手できます。 |
セキュリティ プロバイダ データベースは、セキュリティ プロバイダを最初に使用する際に (つまりセキュリティ プロバイダを含むセキュリティ レルムがデフォルトの (アクティブな) セキュリティ レルムとして設定される前に)、初期化する必要があります。この初期化は、以下の場合に行うことができます。
セキュリティ プロバイダ データベースは、少なくとも、WebLogic Server で提供されるデフォルトのグループ、セキュリティ ポリシー、セキュリティ ロールで初期化されます。詳細については、『WebLogic セキュリティ プロバイダの開発』の「セキュリティ プロバイダと WebLogic リソース」を参照してください。
同じセキュリティ レルムで同じタイプの複数のセキュリティ プロバイダがコンフィグレーションされている場合、それらのセキュリティ プロバイダでは同じセキュリティ プロバイダ データベースを使用できます。この動作は、すべての WebLogic セキュリティ プロバイダおよびサンプル セキュリティ プロバイダ (Oracle Technology Network (OTN) の http://www.oracle.com/technology/community/welcome-bea/index.html 入手可能) で同じように機能します。
たとえば、デフォルト セキュリティ レルム (myrealm) で 2 つの WebLogic 認証プロバイダをコンフィグレーションする場合、それらの WebLogic 認証プロバイダは両方とも組み込み LDAP サーバの同じ位置をセキュリティ プロバイダ データベースとして使用し、したがって同じユーザとグループを使用します。さらに、WebLogic 認証プロバイダの 1 つにユーザまたはグループを追加すると、他の WebLogic 認証プロバイダでもそのユーザまたはグループが表示されます。
| 注意 : | 同じタイプの 2 つの WebLogic セキュリティ プロバイダ (またはサンプル セキュリティ プロバイダ) が 2 つの異なるセキュリティ レルムでコンフィグレーションされている場合は、それぞれが独自のセキュリティ プロバイダ データベースを使用します。一度にアクティブにできるのは、1 つのセキュリティ レルムだけです。 |
独自に開発したカスタム セキュリティ プロバイダ (またはサード パーティ セキュリティ ベンダのカスタム セキュリティ プロバイダ) は、セキュリティ プロバイダの各インスタンスが独自のデータベースを使用するように、またはセキュリティ レルムのすべてのセキュリティ プロバイダ インスタンスが同じデータベースを共有するように設計できます。これは、既存のシステムとセキュリティ要件に基づいて決断する必要のある設計上の決定事項です。セキュリティ プロバイダに関する設計上の決定事項の詳細については、『WebLogic セキュリティ プロバイダの開発』の「設計上の考慮事項」を参照してください。
WebLogic Server では、組み込み LDAP サーバが、WebLogic セキュリティ プロバイダ用のユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーを格納するデータベースとして使用されます。組み込み LDAP サーバは、適度に小規模な環境 (ユーザ数 10,000 以下) 向けのプロダクション レベルの完全な LDAP サーバです。この推奨値より大きい規模にする必要のあるアプリケーションでは、組み込み LDAP サーバは、将来的にプロダクション デプロイメント用の外部 LDAP サーバにエクスポートする際の、優秀な開発、統合およびテスト環境として使用できます。組み込み LDAP サーバでは、以下のアクセスおよび格納機能がサポートされています。
表 4-1 に、各 WebLogic セキュリティ プロバイダによる組み込み LDAP サーバの使用方法を示します。
WebLogic Server では、外部 RDBMS を以下のセキュリティ プロバイダが使用するデータストアとして使用することができます。
セキュリティ レルム内に RDBMS セキュリティ ストアがコンフィグレーションされている場合、セキュリティ レルム内に作成されている上記のいずれかのセキュリティ プロバイダのインスタンスは、自動的に RDBMS セキュリティ ストアのみをデータストアとして使用し、組み込み LDAP サーバは使用しません。その他の WebLogic セキュリティ プロバイダは、それぞれのデフォルト ストアを使用します。たとえば、WebLogic 認証プロバイダは組み込み LDAP サーバを使用します。
RDBMS セキュリティ ストアはドメインの作成時にコンフィグレーションすることをお勧めします。このプロセスを簡素化するようにコンフィグレーション ウィザードが改良されました。これにより、ドメインの起動時にドメインへのアクセスに必要なセキュリティ ポリシーが外部 RDBMS から確実に取得されるようになります。
RDBMS セキュリティ ストアは、クラスタ環境のようにドメイン内の複数の WebLogic Server インスタンスで SAML 2.0 サービスを使用する場合に必要になります。RDBMS セキュリティ ストアについては、『WebLogic Server のセキュリティ』の「RDBMS セキュリティ ストアの管理」を参照してください。
以下の節では、WebLogic Server で使用できるセキュリティ プロバイダのタイプを説明します。
| 注意 : | 複数のタイプのプロバイダを結合した単一のセキュリティ プロバイダを開発することはできません。たとえば、認可とロール マッピングを行う 1 つのセキュリティ プロバイダを開発することはできません。 |
認証プロバイダを使用すると、WebLogic Server ではユーザを検証することで信頼を確立できます。WebLogic Server のセキュリティ アーキテクチャは、ユーザ名とパスワードの認証、証明書とダイジェストの認証 (WebLogic Server を直接用いる)、および HTTP 証明書に基づく認証 (外部の Web サーバを介して行う) を実行する認証プロバイダをサポートします。
| 注意 : | ID アサーション プロバイダは、境界に基づく認証と複数のセキュリティ トークン タイプ/プロトコルを処理する特殊なタイプの認証プロバイダです。詳細については、「ID アサーション プロバイダ」を参照してください。 |
認証プロバイダには、ユーザまたはシステムの認証を実際に実行する LoginModule が組み込まれています。認証プロバイダは、プリンシパル (ユーザ/グループ) に対する署名と信頼性の確認によって追加のセキュリティを提供するプリンシパル検証プロバイダも使用します。プリンシパル検証プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
セキュリティ レルムには少なくとも 1 つの認証プロバイダが必要です。1 つのセキュリティ レルムに複数の認証プロバイダをコンフィグレーションすることもできます。複数の認証プロバイダをコンフィグレーションすると、それぞれが異なる認証を実行する複数の LoginModule を使用できます。管理者は、各認証プロバイダをコンフィグレーションして、ユーザがシステムにログインするときに複数の LoginModule がどのように呼び出されるのかを指定します。認証プロバイダは認証で使用されるプリンシパルにセキュリティを追加するので、プリンシパル検証プロバイダは認証プロバイダからアクセス可能である必要があります。
認証プロバイダと LoginModule の詳細については、『WebLogic セキュリティ プロバイダの開発』の「認証プロバイダ」を参照してください。
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-CSIv(2) を処理できます。Microsoft Passport などのさまざまなトークン タイプをサポートするカスタム ID アサーション プロバイダを記述することもできます。認証プロバイダの LoginModule と一緒に使用すると、ID アサーション プロバイダはシングル サインオンをサポートします。たとえば、ID アサーション プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザは何度もサインオンを求められることはありません。
| 注意 : | X.501 および X.509 証明書に対して WebLogic ID アサーション プロバイダを使用するには、WebLogic Server 製品に付属しているデフォルトのユーザ名マッパー (weblogic.security.providers.authentication.DefaultUserNameMapperImpl) を使用するか、または独自の weblogic.security.providers.authentication.UserNameMapper インタフェースの実装を用意するかのいずれかの方法があります。詳細については、『WebLogic セキュリティ プロバイダの開発』の「カスタム 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 アサーション プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「ID アサーション プロバイダ」を参照してください。
プリンシパル検証プロバイダは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ プロバイダです。一部の LoginModule は RMI クライアントの代わりにリモートで実行することができ、プログラムによるサーバ呼び出しから次のサーバ呼び出しまでの間、認証済みのサブジェクトがクライアント アプリケーション コードに保持できるので、認証プロバイダはプリンシパル検証プロバイダを利用してそのサブジェクト内に格納されているプリンシパルのセキュリティを保護する追加対策を講じます。
プリンシパル検証プロバイダは、プリンシパルに対する署名と信頼性の確認によってそのようなセキュリティを保護する追加対策を講じます。このプリンシパル検証によって、信頼度は向上し、悪意あるプリンシパルによる改ざんの可能性が低下します。サブジェクトのプリンシパルの検証は、WebLogic Server で各呼び出しの RMI クライアント要求がデマーシャリングされる際に行われます。サブジェクトのプリンシパルの信頼性も、認可判定の際に検証されます。
セキュリティ レルムには少なくとも 1 つの認証プロバイダが必要なので、セキュリティ レルムにはプリンシパル検証プロバイダも 1 つ必要です。複数の認証プロバイダがある場合は、それぞれに対応するプリンシパル検証プロバイダが必要です。
| 注意 : | WebLogic Server Administration Console を使用して、プリンシパル検証プロバイダを直接コンフィグレーションすることはできません。WebLogic Server によって認証プロバイダのコンフィグレーション時に、必要なプリンシパル検証プロバイダがコンフィグレーションされます。 |
プリンシパル検証プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
認可プロバイダは、ユーザまたはグループに付与されたセキュリティ ロールと、要求された WebLogic リソースに割り当てられたセキュリティ ポリシーに基づいて WebLogic リソースへのアクセスを制御します。WebLogic リソース、セキュリティ ロール、およびセキュリティ ポリシーの詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。
認可プロバイダの中には、アクセス決定があります。アクセス決定は、WebLogic リソースに対して特定の操作を実行するパーミッションがサブジェクトにあるかどうかを実際に判断します。詳細については、『WebLogic セキュリティ プロバイダの開発』の「プリンシパル検証プロバイダ」を参照してください。
セキュリティ レルムには少なくとも 1 つの認可プロバイダが必要であり、セキュリティ レルムで複数の認可プロバイダをコンフィグレーションすることもできます。複数の認可プロバイダをコンフィグレーションすると、より高度なモジュール設計に従うことができます。たとえば、Web アプリケーションおよびエンタープライズ JavaBean (EJB) のパーミッションを処理する認可プロバイダに加えて、他のタイプの WebLogic リソースのパーミッションを処理する認可プロバイダをコンフィグレーションしたり、国内の従業員のパーミッションを処理する認可プロバイダと、海外の従業員のパーミッションを処理する別の認可プロバイダをコンフィグレーションしたりできます。
WebLogic Server には、以下に示すバルク アクセス バージョンの認可プロバイダ SSPI インタフェースがあります。
バルク アクセス SSPI インタフェースを使用すると、認可プロバイダにおいて 1 回の呼び出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
認可プロバイダとアクセス決定の詳細については、『WebLogic セキュリティ プロバイダの開発』の「認可プロバイダ」を参照してください。
認可プロバイダの一部として、アクセス決定は特定の WebLogic リソースにアクセスするためのパーミッションがサブジェクトにあるかどうかを判断します。したがって、複数の認可プロバイダがコンフィグレーションされている場合は、「アクセス可能か」の問いに対してそれぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAIN のいずれかです。複数の認可プロバイダのアクセス決定の回答が一致しない場合にどうするかを決定するのは、裁決プロバイダの主な役割です。裁決プロバイダは、各アクセス決定の回答を比較検討し最終結果を返すことで認可上の衝突を解消します。認可プロバイダが 1 つだけで、裁決プロバイダがない場合、その 1 つの認可プロバイダのアクセス決定から返される ABSTAIN は DENY のように処理されます。
| 注意 : | WebLogic 裁決プロバイダでは、WebLogic Server Administration Console を使用して、決定の放棄を許可または拒否のいずれとして処理するかを制御できます。 |
裁決プロバイダは、コンフィグレーションされている認可プロバイダが複数の場合のみセキュリティ レルムでコンフィグレーションする必要があります。セキュリティ レルムでコンフィグレーションできる裁決プロバイダは 1 つだけです。
| 注意 : | デフォルトのセキュリティ レルムには認可プロバイダが 1 つしかないので、裁決プロバイダが提供されていても必要ありません。ただし、互換性レルムには認可プロバイダが 2 つあるので、そのレルムでは裁決プロバイダが必要です。 |
WebLogic Server には、以下に示すバルク アクセス バージョンの裁決プロバイダ SSPI インタフェースがあります。
バルク アクセス SSPI インタフェースを使用すると、裁決プロバイダにおいて 1 回の呼び出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
裁決プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「裁決プロバイダ」を参照してください。
ロール マッピング プロバイダでは、指定された WebLogic リソースについて要求側に付与されるセキュリティ ロール群を計算によって取得することで、動的ロール関連付けをサポートします。WebLogic Security フレームワークは、特定の WebLogic リソースにアクセスする必要があるときに特定のサブジェクトにどのセキュリティ ロールが適用されるのかを以下のようにして判断します。
ロール マッピング プロバイダから認可プロバイダにこのセキュリティ ロール情報が提供されるので、認可プロバイダは、ロールベースのセキュリティを用いる WebLogic リソース (すなわち、Web アプリケーションやエンタープライズ JavaBean コンテナのリソース) に「アクセスできるか」という質問に答えることができます。
セキュリティ ロールは J2EE デプロイメント記述子に設定するか、WebLogic Server Administration Console を使って作成します。デプロイメント記述子に設定されたセキュリティ ロールはデプロイ時に適用されます (デプロイメント記述子を無視することにした場合を除く)。
セキュリティ レルムには少なくとも 1 つのロール マッピング プロバイダが必要であり、セキュリティ レルムで複数のロール マッピング プロバイダをコンフィグレーションすることもできます。複数のロール マッピング プロバイダをコンフィグレーションすると、従来のインフラストラクチャ要件の範囲内で作業することも (たとえばユーザおよびセキュリティ ロールの情報が含まれる各 LDAP サーバにつき 1 つのロール マッピング プロバイダをコンフィグレーションする)、または高度なモジュール設計に従うこともできます (たとえば Web アプリケーションおよびエンタープライズ JavaBean (EJB) のマッピングを処理するロール マッピング プロバイダと、他のタイプの WebLogic リソースのマッピングを処理する別のロール マッピング プロバイダをコンフィグレーションする)。
| 注意 : | 複数のロール マッピング プロバイダがコンフィグレーションされている場合には、WebLogic Security フレームワークは、そのすべてのロール マッピング プロバイダから返されるセキュリティ ロール群の論理積を取ります。つまり、すべてのロール マッピング プロバイダからのセキュリティ ロール名が、重複を削除して 1 つのリストに結合されます。 |
WebLogic Server には、以下に示すバルク アクセス バージョンのロール マッピング プロバイダ SSPI インタフェースがあります。
バルク アクセス SSPI インタフェースを使用すると、ロール マッピング プロバイダにおいて、1 回の呼び出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。
ロール マッピング プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「ロール マッピング プロバイダ」を参照してください。
監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布します。監査プロバイダは、特定の監査基準 (重大度など) に基づいて特定のイベントを監査するかどうかを決定します。また、監査プロバイダは LDAP ディレクトリ、データベース、シンプル ファイルなどの出力リポジトリに監査情報を書き込むことができます。セキュリティ担当者の呼び出しなどの特定のアクションも監査プロバイダの一部としてコンフィグレーションすることができます。
他のタイプのセキュリティ プロバイダ (認証や認可など) は、WebLogic Security フレームワークを介して呼び出しを行うことによって、セキュリティ操作の実行前と実行後に監査サービスを要求できます。詳細については、『WebLogic セキュリティ プロバイダの開発』の「カスタム セキュリティ プロバイダからのイベントの監査」を参照してください。
監査プロバイダはセキュリティ レルムで複数をコンフィグレーションできますが、必須ではありません。
監査プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「監査プロバイダ」を参照してください。
資格マップは、WebLogic Server で使用される資格から、レガシー システムまたはリモート システムで使用される資格へのマッピングであり、そのシステムの特定のリソースへの接続方法を WebLogic Server に指示します。つまり、資格マップを使用することで、WebLogic Server が、認証済みのサブジェクトに代わってリモート システムにログインできるようになります。
資格マッピング プロバイダでは、ユーザ名とパスワードの組み合わせ、SAML アサーション、公開鍵証明書、エリアスと資格タイプの組み合わせといった複数種の資格を処理できます。資格マッピングはデプロイメント記述子で設定しても、WebLogic Server Administration Console を使って設定してもかまいません。これらの資格マッピングはデプロイ時に適用されます (それらの資格マッピングを無視することにした場合を除く)。
セキュリティ レルムには少なくとも 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 アサーションのみを生成します。 |
資格マッピング プロバイダの詳細については、『WebLogic セキュリティ プロバイダの開発』の「資格マッピング プロバイダ」を参照してください。
証明書の検索と検証のプロバイダは、証明書のパスを完了させ、X509 証明書チェーンを検証します。CLV プロバイダには、2 つのタイプがあります。
証明書パス ビルダと証明書パス検証プロバイダは、セキュリティ レルムに少なくとも 1 つずつコンフィグレーションする必要があります。1 つのセキュリティ レルムに、複数の証明書パス検証プロバイダをコンフィグレーションすることもできます。複数のプロバイダをコンフィグレーションした場合は、すべての証明書パス検証プロバイダの検証が正常に終了しないと、証明書または証明書チェーンは有効になりません。
WebLogic Server では、CLV プロバイダの機能を WebLogic 証明書パス プロバイダと証明書レジストリで提供します。
キーストアを使用すると、パスワードで保護された、プライベート キー (およびプライベート キーに関連付けられた公開鍵証明書) と信頼性のある認証局のストアを作成および管理できます。
WebLogic Server 製品の一部として含まれる WebLogic キーストア プロバイダは、保護されたプライベート キーをキーストアから取得するために使用されます。
| 注意 : | WebLogic キーストア プロバイダはこのリリースの WebLogic Server では非推奨となっていますが、引き続きサポートされています。カスタム キーストア プロバイダの開発はサポートされていません。代わりに、WebLogic の ID キーストアと信頼キーストア、または Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、これらのキーストアを使用することで利用できます。WebLogic キーストア プロバイダは、下位互換性を保持するためにのみサポートされています。WebLogic キーストア プロバイダは、WebLogic Server 7.0 コンフィグレーションと下位互換性を保持する必要がある場合にのみ使用することをお勧めします。Java キーストアの使い方については、『WebLogic Server のセキュリティ』の「プロダクション用のキーストアのコンフィグレーション」を参照してください。 |
レルム アダプタ プロバイダは、既存のバージョン 6.x セキュリティ レルムを WebLogic Server のこのリリースのセキュリティ機能と併用できるようにすることで、バージョン 6.x WebLogic セキュリティ レルムとの下位互換性を提供するものです。レルム アダプタ プロバイダは、WebLogic Server 6.x で使用されるレルム API (weblogic.security.acl) を WebLogic Server のこのリリースで使用される API にマップします。図 4-2 に互換性レルムとサポートされるセキュリティ プロバイダのタイプを示します。
表 4-2 に、1 つのセキュリティ レルムで同じタイプの複数のセキュリティ プロバイダをコンフィグレーションできるかどうかを示します。
すべてのセキュリティ プロバイダは、セキュリティ レルムのコンテキスト内に存在します。以前の WebLogic Server リリース 6.x を使用しているのでなければ、デフォルト レルム (つまり myrealm と呼ばれるアクティブなセキュリティ レルム) としてあらかじめ定義されている WebLogic Server セキュリティ レルムには図 4-3 に示す WebLogic セキュリティ プロバイダが用意されています。
| 注意 : | リリース 6.x からこのリリースへアップグレードしている場合には、最初にあらかじめ用意されているものは互換性レルム (最初はデフォルト レルムとして定義されている) で、それを使用すれば既存のコンフィグレーションをそのまま扱うことができます。ただし、6.x モデルは非推奨になっているので、セキュリティ レルムをこのリリースの WebLogic Server で使用可能なセキュリティ モデルにアップグレードする必要があります。 |
セキュリティ プロバイダは WebLogic Server セキュリティ レルムに「プラグイン」される個別のモジュールまたはコンポーネントなので、手間をかけずに追加、置換、または削除できます。WebLogic セキュリティ プロバイダ、独自に開発したカスタム セキュリティ プロバイダ、サード パーティ セキュリティ ベンダのセキュリティ プロバイダ、または以上 3 つの組み合わせを使用して完全に機能するセキュリティ レルムを作成できます。ただし、図 4-3 にも示すように、一部のタイプのセキュリティ プロバイダはセキュリティ レルムが正しく機能する上で必須の要素です。表 4-3 は、セキュリティ レルムが完全に機能するためにどのセキュリティ プロバイダをコンフィグレーションしなければならないかを説明しています。
|
セキュリティ レルムの詳細については、『WebLogic Server のセキュリティ』の「セキュリティ管理の概要」を参照してください。
  
|