WebLogic Security の紹介
|
 |
 |
|
この節では、WebLogic Security サービスのアーキテクチャについて説明します。アーキテクチャは、以下の節で説明する 3 つの主要なコンポーネントで構成されています。
図 4-1 に、WebLogic Security フレームワークの概観を示します。 フレームワークは、weblogic.security.service パッケージのインタフェース、クラス、および例外で構成されます。
図 4-1 WebLogic Security サービスのアーキテクチャ
WebLogic Security フレームワークの主な役割は、簡素化されたアプリケーション プログラミング インタフェース (API) を提供することです。API は、セキュリティ サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。そのコンテキスト内で WebLogic Security フレームワークは、WebLogic コンテナ (Web および EJB)、リソース コンテナ、セキュリティ プロバイダの間の仲介役としても機能します。
以下の節では、WebLogic Security フレームワークを介した WebLogic コンテナ、リソース コンテナ、各セキュリティ プロバイダの間の対話について説明します。
図 4-2 に、ファットクライアント ログインの認証プロセスを示します。JAAS はサーバ上で動作してログインを実行します。シンクライアント ログイン (Web ブラウザ クライアント) の場合でも、JAAS はサーバ上で動作します。
注意 : JAAS プロセスを直接扱うのは、カスタム認証プロバイダの開発者だけです。クライアント アプリケーションは、JNDI 初期コンテキストまたは JAAS のいずれかを使用してユーザ名とパスワードを受け渡します。
ユーザがユーザ名とパスワードの組み合わせを使用してシステムにログインしようとすると、WebLogic Server はそのユーザのユーザ名とパスワードを検証することによって信頼を確立し、JAAS の要件に従って、プリンシパルが格納されたサブジェクトを返します。図 4-2 で示されているとおり、このプロセスには LoginModule とプリンシパル検証プロバイダの使用が必要になります。プリンシパル検証プロバイダの詳細については、「WebLogic プリンシパル検証プロバイダ」を参照してください。
呼び出し側の ID の検証に成功すると、認証コンテキストが確立され、ID 検証済みのユーザまたはシステムは、そのコンテキストを通じて他のエンティティに対する認証を行うことができます。認証コンテキストはまた、アプリケーション コンポーネントに委託することもでき、それによって、そのコンポーネントは別のアプリケーション コンポーネントを呼び出しつつ、元の呼び出し側として動作できるようになります。
ID アサーション プロバイダは、境界認証プロセスの一部として使用されます。境界認証が使用される場合 (図 4-3 を参照)、 WebLogic Server ドメインの外部のトークンが、セキュリティ レルム内の、そのタイプのトークンの検証を担当し、「アクティブ」としてコンフィグレーションされている ID アサーション プロバイダに渡されます。そのトークンの有効性が問題なく検証されれば、ID アサーション プロバイダはそのトークンを WebLogic Server ユーザ名にマップし、そのユーザ名を WebLogic Server に送り返します。その後 WebLogic Server では、認証プロセスが続行されます。具体的には、ユーザ名が JAAS CallbackHandler を通じて送信され、コンフィグレーションされている各認証プロバイダの LoginModule に渡されるので、LoginModule はサブジェクト内に適切なプリンシパルを格納できるようになります。
注意 : X.501 および X.509 証明書に対して WebLogic ID アサーション プロバイダを使用するには、WebLogic Server 製品に付属しているデフォルトのユーザ名マッパー (weblogic.security.providers.authentication.DefaultUserNameMapperImpl) を使用するか、または独自の weblogic.security.providers.authentication.UserNameMapper インタフェースの実装を用意するかのいずれかの方法があります。詳細については、『WebLogic Security サービスの開発』の「カスタム ID アサーション プロバイダを開発する必要があるか」を参照してください。
図 4-3 でも示されているように、境界認証では認証プロセスと同じ構成要素が必要ですが、ID アサーション プロバイダも追加されます。
図 4-4 に示すとおり、ユーザはユーザ名とパスワードの組み合わせを使ってシステムにログインしようとします。WebLogic Server は、コンフィグレーション済みの認証プロバイダの LoginModule を呼び出すことによって信頼を確立します。LoginModule は、ユーザのユーザ名とパスワードを検証し、JAAS の要件に従って、プリンシパルが格納されたサブジェクトを返します。
WebLogic Server は、指定されたプリンシパル検証プロバイダにサブジェクトを渡します。プリンシパル検証プロバイダは、そのプリンシパルに署名して、それらを WebLogic Server を通じてクライアント アプリケーションに返します。他のセキュリティ操作のためにサブジェクト内のプリンシパルが必要になった場合、同じプリンシパル検証プロバイダが、そのプリンシパルが署名時から変更されていないかどうかを検証します。
図 4-5 に、認可プロセスにおける認可プロバイダ (および関連する裁決プロバイダとロール マッピング プロバイダ) と WebLogic Security フレームワークとの対話を示します。
ユーザまたはシステム プロセスが WebLogic リソースを要求し、特定の操作を実行しようとすると、認可プロセスが開始されます。要求された WebLogic リソースのタイプを処理するリソース コンテナがリクエストを受け取ります。たとえば EJB コンテナは EJB リソースに対するリクエストを受け取ります。リソース コンテナは、WebLogic Security フレームワークを呼び出して、リクエストのサブジェクト、要求されている WebLogic リソースなどの情報を含むリクエスト パラメータを渡します。WebLogic Security フレームワークは、コンフィグレーション済みのロール マッピング プロバイダを呼び出して、ロール マッピング プロバイダが使用できる形式でリクエスト パラメータを渡します。ロール マッピング プロバイダは、リクエスト パラメータを使用して、要求側のサブジェクトが資格を有する一連のロールを計算し、該当するロールを WebLogic Security フレームワークに渡します。認可プロバイダは、そのサブジェクトが WebLogic リソースに対して要求されたアクションを実行できる資格があるかどうかを判別します (つまり、アクセス決定を行います)。複数の認可プロバイダがコンフィグレーションされている場合には、WebLogic Security フレームワークは、認可プロバイダから返されたアクセス決定に衝突があった場合、その調停を裁決プロバイダに委託します。裁決プロバイダでは、認可判定の最終結果を決定します。
複数の認可プロバイダがコンフィグレーションされている場合 (図 4-5 を参照) には、複数のアクセス決定を調停し、判定するための裁決プロバイダが必要になります。 裁決プロバイダは TRUE か FALSE の判定を認可プロバイダに返し、認可プロバイダはその判定を WebLogic Security フレームワークを通してリソース コンテナに転送します。
WebLogic Security フレームワークは、認可判定の一環として、セキュリティ レルム用にコンフィグレーションされている各ロール マッピング プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。
動的なロール関連付けを作成する場合のロール マッピング プロバイダと WebLogic Security フレームワークとの対話を図 4-6 に示します。
ユーザまたはシステム プロセスが WebLogic リソースを要求し、特定の操作を実行しようとすると、ロール マッピング プロセスが開始されます。要求された WebLogic リソースのタイプを処理するリソース コンテナがリクエストを受け取ります。たとえば EJB コンテナは EJB リソースに対するリクエストを受け取ります。リソース コンテナは、WebLogic Security フレームワークを呼び出して、リクエストのサブジェクト、要求されている WebLogic リソースなどの情報を含むリクエスト パラメータを渡します。WebLogic Security フレームワークは、適用するロールのリストを取得するために、コンフィグレーション済みの各ロール マッピング プロバイダを呼び出します。要求側に特定のロールの資格があるとセキュリティ ポリシーに指定されている場合には、そのロールがサブジェクトに適用されるロールのリストに追加されます。このプロセスは、WebLogic リソースまたはリソース コンテナに適用されるセキュリティ ポリシーがすべて評価されるまで続行されます。ロールのリストは WebLogic Security フレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。
ロール マッピング プロバイダによる動的ロール関連付けの結果、一連のロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのロールを用いて、保護対象 WebLogic リソース、リソース コンテナ、およびアプリケーション コードについての認可判定が行われます。たとえば、エンタープライズ JavaBean (EJB) であれば、アクセスを許可するかどうかを決めるビジネス ポリシーを知らなくても、J2EE (Java 2 Enterprise Edition) の isCallerInRole() メソッドを用いてデータベース内のレコードからフィールドを取得することができます。
図 4-7 に、監査プロバイダが WebLogic Security フレームワークと他のタイプのセキュリティ プロバイダ (ここでは認証プロバイダ) と対話する仕組みを示します。
リソース コンテナが、ログイン リクエストの一部としてユーザの認証情報 (ユーザ名とパスワードの組み合わせなど) を WebLogic Security フレームワークに渡すと、監査プロセスが開始されます。WebLogic Security フレームワークは、ログイン リクエストに関連付けられている情報をコンフィグレーション済みの認証プロバイダに渡します。認証プロバイダが認証サービスを提供するほかに監査イベントをポストする場合、認証プロバイダは AuditEvent オブジェクトをインスタンス化します。AuditEvent オブジェクトには、監査対象のイベント タイプや監査の重大度レベルなどの情報が含まれます。その後、認証プロバイダは WebLogic Security フレームワーク内の監査サービスを呼び出して、AuditEvent オブジェクトを渡します。監査サービスは、AuditEvent オブジェクトをコンフィグレーション済みの監査プロバイダの実行時クラスに渡し、監査イベントの記録を有効にします。監査プロバイダの実行時クラスは、AuditEvent オブジェクトから取得した情報を使用して監査レコードの内容を管理します。AuditEvent オブジェクト内に認証プロバイダによって指定された監査条件が満たされると、該当する監査プロバイダの実行時クラスは監査レコードを書き出します。監査プロバイダの実装によっては、監査記録をファイルやデータベースなどの永続ストレージ メディアに書き込むことができます。
資格マッピング プロセスにおける資格マッピング プロバイダと WebLogic Security フレームワークとの対話を図 4-8 に示します。
JavaServer Page (JSP)、サーブレット、エンタープライズ JavaBean (EJB)、リソース アダプタなどのアプリケーション コンポーネントが、エンタープライズ情報システム (EIS) (たとえば、Oracle、SQL Server などのリレーショナル データベース) にアクセスするために、適切なリソース コンテナを通じて WebLogic Security フレームワークを呼び出すと、資格マッピング プロセスが開始されます。呼び出しの中で、アプリケーション コンポーネントは、サブジェクト (「誰が」要求しているのか)、WebLogic リソース (「何を」要求しているのか)、および WebLogic リソースにアクセスするために必要な資格のタイプについての情報を渡します。WebLogic Security フレームワークは、資格に対するアプリケーション コンポーネントのリクエストを、アプリケーション コンポーネントが必要としている資格のタイプを処理するコンフィグレーション済み資格マッピング プロバイダに送信します。資格マッピング プロバイダは、そのデータベースを照会して、アプリケーション コンポーネントが要求しているものに一致する資格群を取得し、WebLogic Security フレームワークに資格を返します。 WebLogic Security フレームワークは、リソース コンテナを通じて要求側のアプリケーション コンポーネントに資格を返します。アプリケーション コンポーネントは、資格を使用して外部システムにアクセスします。
Microsoft クライアントによる SSO では、シングル パス ネゴシエート ID アサーション プロバイダを使用してサーブレット コンテナや WebLogic Security フレームワークと対話することで認証を行います。
ブラウザがネゴシエート認証スキームをサポートできる場合は、Kerberos キー配布センター (KDC) にコンタクトしてチケットを入手します。
このチケットの情報を使用して、サポートする GSS メカニズム トークン タイプを含む SPNEGO トークンを作成します。
次に、このトークンを Base64 でエンコードし、元の GET メッセージの Authorization ヘッダを使用してアプリケーション サーバに返信します。次に例を示します。
GET...
Authorization: Negotiate <Base64 encoded SPNEGO token>
WebLogic Server のこのリリースでのセキュリティは、一連のセキュリティ サービス プロバイダ インタフェース (SSPI) に基づいています。開発者およびサードパーティ ベンダは、SSPI を使用して WebLogic Server 環境向けのセキュリティ プロバイダを開発できます。認証、ID アサーション、認可、監査、裁決、ロール マッピング、および資格マッピング用の SSPI が利用可能です。
注意 : キーストア プロバイダ用の SSPI はこのリリースの WebLogic Server では非推奨となっています。代わりに Java キーストア (JKS) を使用してください。Java キーストアの使い方については、『WebLogic Security の管理』 の「キーストアのコンフィグレーション」を参照してください。
SSPI を使用すると、カスタム セキュリティ プロバイダで WebLogic Server リソースを保護することができます。SSPI を使用してカスタム セキュリティ プロバイダを開発することも、サードパーティ ベンダからカスタム セキュリティ プロバイダを購入することもできます。
注意 : カスタム セキュリティ プロバイダの開発を支援するために、サンプル カスタム セキュリティ プロバイダが用意されています。BEA dev2dev Web サイト (http://www.beasys.co.jp/dev2dev/code/index.html) で入手できます。カスタム セキュリティ プロバイダの開発の詳細については、『WebLogic Security サービスの開発』を参照してください。
この節では、WebLogic Server 製品に付属している WebLogic セキュリティ プロバイダについて説明します。セキュリティ プロバイダは、WebLogic Server のセキュリティ レルムに「プラグイン」してアプリケーションにセキュリティ サービスを提供するためのモジュールです。セキュリティ プロバイダは、アプリケーションの代わりに WebLogic Security フレームワークに働きかけを行います。
WebLogic Server 製品に付属している WebLogic セキュリティ プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム セキュリティ プロバイダで補足するか、あるいはカスタム セキュリティ プロバイダに置き換えることができます。カスタム セキュリティ プロバイダは以下のようにして開発します。
weblogic.security.spi パッケージから適切なセキュリティ サービス プロバイダ インタフェース (SSPI) を実装してセキュリティ プロバイダの実行時クラスを作成する。詳細については、『WebLogic Security サービスの開発』を参照してください。
図 4-9 に、WebLogic セキュリティ レルムにおいて必須および省略可能なセキュリティ プロバイダを示します。
以下の節では、WebLogic セキュリティ プロバイダについて説明します。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 認証プロバイダが含まれています。WebLogic 認証プロバイダは、ユーザ名とパスワードの委託認証とダイジェスト認証をサポートし、組み込み LDAP サーバを利用してユーザとグループの情報を格納します。このプロバイダを使用すると、ユーザとグループ メンバシップを編集、表示、および管理できます。
注意 : WebLogic 認証プロバイダを WebLogic 認可プロバイダと組み合わせれば、WebLogic Server リリース 6.x で利用できたファイル レルムの機能の代わりになります。
WebLogic Server では、デフォルトのセキュリティ レルムにおいて、以下の認証プロバイダを WebLogic 認証プロバイダの代わりとして使用したり、WebLogic 認証プロバイダと併用したりできます。
注意 : デフォルトでは、これらの認証プロバイダは使用可能ですが、WebLogic デフォルト セキュリティ レルムにはコンフィグレーションされていません。
WebLogic ID アサーション プロバイダでは、X.509 証明書を使用した証明書認証および CSIv2 (CORBA Common Secure Interoperability version 2) ID アサーションがサポートされています。
WebLogic ID アサーション プロバイダはトークン タイプを検証し、X.509 デジタル証明書と X.501 識別名を WebLogic ユーザ名にマップします。また、CSIv2 ID アサーションに使用する信頼性のあるクライアント プリンシパルのリストも指定します。ワイルドカード文字 (*) を使用すると、すべてのプリンシパルに信頼性があると指定できます。クライアントが信頼性のあるクライアント プリンシパルのリストにない場合は、CSIv2 ID アサーションが失敗し、呼び出しが拒否されます。
WebLogic ID アサーション プロバイダでは、以下のトークン タイプがサポートされています。
AU_TYPE - WebLogic AuthenticatedUser がトークンとして使用される場合に使用します。X509_TYPE - X.509 クライアント証明書がトークンとして使用される場合に使用します。CSI_PRINCIPAL_TYPE - CSIv2 プリンシパル名 ID がトークンとして使用される場合に使用します。 CSI_ANONYMOUS_TYPE - CSIv2 匿名 ID がトークンとして使用される場合に使用します。 CSI_X509_CERTCHAIN_TYPE - CSIv2 X509 証明書チェーン ID がトークンとして使用される場合に使用します。 CSI_DISTINGUISHED_NAME_TYPE - CSIv2 識別名 ID がトークンとして使用される場合に使用します。 シングル パス ネゴシエート ID アサーション プロバイダは、SPNEGO プロトコルをサポートする Microsoft クライアントでの SSO に使用します。具体的には、SPNEGO トークンをデコードして Kerberos トークンを入手し、この Kerberos トークンを検証して WebLogic ユーザにマップします。シングル パス ネゴシエート ID アサーション プロバイダでは、Java GSS (Generic Security Service) アプリケーション プログラム インタフェース (API) を使用して、Kerberos を介して GSS セキュリティ コンテキストを受け付けます。Java GSS API の詳細については、http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/jgss-features.html を参照してください。
シングル パス ネゴシエート ID アサーション プロバイダは、WebLogic サーブレット コンテナと対話します。このコンテナが、WWW-Authenticate ヘッダおよび WWW-Authorization ヘッダを処理して、適切な Negotiate ヘッダを追加します。
デフォルトでは、シングル パス ネゴシエート ID アサーション プロバイダは使用可能ですが、WebLogic デフォルト セキュリティ レルムにはコンフィグレーションされていません。シングル パス ネゴシエート ID アサーション プロバイダは、WebLogic ID アサーション プロバイダの代わりとして使用したり、WebLogic ID アサーション プロバイダと併用したりできます。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic プリンシパル検証プロバイダが含まれています。このプロバイダは、WebLogic Server プリンシパルの署名と検証を行います。言い換えると、WebLogic Server ユーザまたは WebLogic Server グループを表すプリンシパルに対して署名と検証を行います。
注意 : weblogic.security パッケージの WLSPrincipals クラスを使用すると、プリンシパル (ユーザまたはグループ) が WebLogic Server に対して特別な意味を持っているかどうか (それが定義済みの WebLogic Server ユーザまたは WebLogic Server グループであるかどうか) が分かります。さらに、WebLogic Server ユーザまたはグループを表すプリンシパルは、weblogic.security.spi パッケージの WLSUser インタフェースと WLSGroup インタフェースを実装する必要があります。
WebLogic プリンシパル検証プロバイダには、WLSUserImpl および WLSGroupImpl という名前の WLSUser インタフェースおよび WLSGroup インタフェースの実装が含まれています。これらは、weblogic.security.principal パッケージに定義されています。また、PrincipalValidatorImpl という名前の PrincipalValidator SSPI の実装も含まれています。PrincipalValidator SSPI の詳細については、『WebLogic Security サービスの開発』の「PrincipalValidator SSPI を実装する」を参照してください。
ID アサーション プロバイダが特定のタイプのトークンをサポートするのと同じように、プリンシパル検証プロバイダは特定のタイプのプリンシパルに対する署名と信頼性の確認を行います。そのため、WebLogic プリンシパル検証プロバイダを使用して、WebLogic Server ユーザまたは WebLogic Server グループを表すプリンシパルに対して署名と検証を行うことができます。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 認可プロバイダが含まれています。このプロバイダは、WebLogic Server のこのバージョンの認可機能をデフォルトで適用するものです。WebLogic 認可プロバイダは、特定のユーザが保護対象の WebLogic リソースへのアクセスを許可されているかどうかを判定するため、ポリシーベースの認可エンジンを使用してアクセス決定を返します。また、WebLogic 認可プロバイダは、システム内のセキュリティ ポリシーのデプロイメントとアンデプロイメントもサポートしています。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 裁決プロバイダが含まれています。このプロバイダは通常、複数の認可プロバイダのアクセス決定から異なる結果が返された場合に裁決を行い、WebLogic リソースへのアクセスを許可するかどうかを最終的に判定します。ただし、デフォルトのセキュリティ レルムには認可プロバイダが 1 つしかなく、生成されるアクセス決定は 1 つのみなので、WebLogic 裁決プロバイダは使用されません。
注意 : 互換性レルムには認可プロバイダが 2 つあるので、そのレルムでは WebLogic 裁決プロバイダが使用されます。
WebLogic 裁決プロバイダには、動作を制御する [完全一致の許可が必要] という属性があります。[完全一致の許可が必要] 属性は、デフォルトでは TRUE に設定されており、WebLogic 裁決プロバイダはその設定に従って次のように動作します。
PERMIT を返した場合、最終的な判定として TRUE を返します (つまり WebLogic リソースへのアクセスは許可されます)。PERMIT を返し、その他が ABSTAIN を返した場合、FALSE を返します (つまり WebLogic リソースへのアクセスは拒否されます)。ABSTAIN または DENY を返した場合、最終的な判定として FALSE を返します (つまり WebLogic リソースへのアクセスは拒否されます)。[完全一致の許可が必要] 属性を FALSE に変更した場合、WebLogic 裁決プロバイダは次のように動作します。
PERMIT を返した場合、最終的な判定として TRUE を返します (つまり WebLogic リソースへのアクセスは許可されます)。PERMIT を返し、その他が ABSTAIN を返した場合、最終的な判定として TRUE を返します (つまり WebLogic リソースへのアクセスは許可されます)。DENY を返した場合、最終的な判定として FALSE を返します (つまり WebLogic リソースへのアクセスは拒否されます)。注意 : [完全一致の許可が必要] 属性は、WebLogic 裁決プロバイダをコンフィグレーションするときに設定します。裁決プロバイダのコンフィグレーションの詳細については、『WebLogic Security の管理』の「WebLogic 裁決プロバイダのコンフィグレーション」を参照してください。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic ロール マッピング プロバイダが含まれています。このプロバイダは、デフォルト ユーザと WebLogic リソースのそれぞれについて、保護されている特定の WebLogic リソースに関する特定のユーザ (サブジェクト) の動的ロールを決定します。また、WebLogic ロール マッピング プロバイダは、システム内のロールのデプロイメントとアンデプロイメントをサポートしています。WebLogic ロール マッピング プロバイダは、WebLogic 認可プロバイダと同じセキュリティ ポリシー エンジンを使用します。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 監査プロバイダが含まれています。このプロバイダは、WebLogic Security フレームワークで内部的に決定された、複数のセキュリティ リクエストの情報を記録します。また、WebLogic 監査プロバイダはこれらのセキュリティ リクエストに関連付けられているイベント データとリクエストの結果も記録します。
WebLogic Server のデフォルト (アクティブ) セキュリティ レルムには WebLogic 資格マッピング プロバイダが含まれています。WebLogic 資格マッピング プロバイダを使用して、WebLogic Server ユーザを、エンタープライズ情報システム (EIS) (たとえば、Oracle、SQL Server などのリレーショナル データベース) にアクセスするためにリソース アダプタで使用すべき適切な資格に関連付ける (つまりマップする) ことができます。プロバイダは、ユーザの認証資格 (ユーザ名とパスワード) をレガシー アプリケーションで必要になる認証資格にマップするので、レガシー アプリケーションは必要な資格情報を取得できます。たとえば、EIS はメインフレーム トランザクション処理システムでも、データベース システムでも、Java プログラミング言語で記述されていないレガシー アプリケーションでもかまいません。
WebLogic Server のユーザおよびグループと他のシステムのユーザ名/パスワードとの間のマッピングであれば、WebLogic 資格マッピング プロバイダで十分です。
WebLogic キーストア プロバイダでは、Sun Microsystems から Java Software Development Kit (SDK) の形で提供されるキーストアの参照実装を使用します。そこでは標準の Java キーストア (JKS) キーストア タイプが利用されますが、これはキーストアをファイル (マシンごとに 1 つ) として実装したものです。各プライベート キーはそれぞれのパスワードで保護されます。WebLogic キーストア プロバイダに関連付けられているキーストア ファイルは 2 つあります。
keytool ユーティリティか WebLogic Server の ImportPrivateKey ユーティリティを利用すれば、このファイルにプライベート キーを追加することができます。なお、WebLogic Server では、このキーストア ファイルからプライベート キーと証明書を取得できます。注意 : WebLogic キーストア プロバイダはこのリリースの WebLogic Server では非推奨となっていますが、引き続きサポートされています。カスタム キーストア プロバイダの開発はサポートされていません。 代わりに Java キーストア (JKS) を使用してください。WebLogic キーストア プロバイダによってサポートされていたすべての機能は、Java キーストアを使用することで利用できます。WebLogic キーストア プロバイダは、下位互換性を保持するためにのみサポートされています。WebLogic キーストア プロバイダは、WebLogic Server 7.0 コンフィグレーションと下位互換性を保持する必要がある場合にのみ使用することをお勧めします。Java キーストアの使い方については、『WebLogic Security の管理』 の「キーストアのコンフィグレーション」を参照してください。
WebLogic レルム アダプタ プロバイダは、既存のバージョン 6.x セキュリティ レルムを WebLogic Server のこのリリースのセキュリティ機能と併用できるようにすることで、バージョン 6.x WebLogic セキュリティ レルムとの下位互換性を提供するものです。WebLogic レルム アダプタ プロバイダは、WebLogic Server 6.x で使用されるレルム API (weblogic.security.acl) を WebLogic Server のこのリリースで使用される API にマップします。以下の WebLogic レルム アダプタ プロバイダが提供されています。
レルム アダプタ認証プロバイダを利用すれば、バージョン 6.x のセキュリティ レルムとそれらのデータ ストアを WebLogic Server の WebLogic セキュリティ プロバイダと併用できるようになります。さらに、weblogic.security.acl.CertAuthenticator クラスの実装を WebLogic Server で使用することも可能になります。レルム アダプタ認証プロバイダには、X.509 トークンに基づいた ID アサーションを提供するコンポーネントが含まれています。
互換性セキュリティでは、WebLogic 認可プロバイダとレルム アダプタ認可プロバイダの 2 種類の認可プロバイダが使用されます。WebLogic 認可プロバイダが新しいセキュリティ ポリシーに使用されるのに対して、レルム アダプタ認可プロバイダは WebLogic Server 6.1 のアクセス制御リスト (ACL) へのマッピングに使用されます。
レルム アダプタ監査プロバイダを利用すれば、互換性セキュリティを使用する WebLogic Server デプロイメントで weblogic.security.audit インタフェースの実装を使用できるようになります。
これらのセキュリティ プロバイダは WebLogic Server Administration Console を使ってコンフィグレーションされますが、既存の 6.x セキュリティ レルムでは WebLogic Server 6.1 に存在するのと同じ MBean とユーザ インタフェースを引き続き使用することになります。
注意 : WebLogic レルム アダプタ プロバイダは非推奨になったため、WebLogic Server 8.1 セキュリティ モデルにアップグレードする間だけ使用してください。
WebLogic Security サービス アーキテクチャは、以下のカテゴリのユーザに対して特にメリットをもたらします。
Web アプリケーションおよび EJB に対するほとんどのセキュリティはシステム管理者によって実装されるので、アプリケーション開発者は、コードで対処すべき特別な考慮事項がない限り、アプリケーションの保護に関する細かい注意点を気にする必要はありません。アプリケーション内でのカスタム セキュリティのプログラミングについても、WebLogic Server アプリケーション開発者は、WebLogic Server で使用されるサブジェクトやプリンシパルに関する情報を取得する (ユーザの情報を特定する) のに BEA が提供するアプリケーション プログラミング インタフェース (API) を利用できます。これらの API は、weblogic.security パッケージに入っています。
WebLogic Server の Java 標準の包括的なサポートにより、WebLogic Server 用のアプリケーションの開発者は、J2EE で定義されたセキュリティ固有のメソッドだけでなく、JAAS、JSSE などの Java プラットフォーム セキュリティ パッケージの API も使用できます。
管理者は、WebLogic Server セキュリティ プロバイダをそのまま使用して、包括的なセキュリティ ソリューションを実装できます。また、管理者は Administration Console を使用して、セキュリティ ロールの定義や WebLogic リソースに対するセキュリティ ポリシーの割り当てを行い、企業独自のビジネス ルールを実現する認可方式を作成できます。
業界をリードするセキュリティ サービス プロバイダのほとんどが、BEA WebLogic Server 8.1 をサポートする計画を発表しています。これらのサードパーティ プロバイダは、セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して、自社の製品を WebLogic Server 環境に統合する予定です。WebLogic セキュリティ プロバイダの基底の統合メカニズムとして SSPI を使用し、WebLogic Server 環境向けのカスタマイズされたセキュリティ プロバイダを開発できます。認証、ID アサーション、認可、監査、裁決、ロール マッピング、および資格マッピング用の SSPI が利用可能です。
注意 : キーストア プロバイダ用の SSPI はこのリリースの WebLogic Server では非推奨となっています。代わりに Java キーストア (JKS) を使用してください。Java キーストアの使い方については、『WebLogic Security の管理』 の「キーストアのコンフィグレーション」を参照してください。
このアーキテクチャを使用することで、セキュリティ開発者は、実装が容易な、密接に統合されたソリューションを提供できます。 その結果、開発要件が緩和され、企業のセキュリティ管理ソリューションの実装時における投資に対する回収率が向上します。
詳細については、「Security Resource Center」を参照してください。
|
|
|