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