WebLogic Security の紹介
|
 |
 |
|
WebLogic Server のセキュリティに関するドキュメントで扱う主な用語は以下のとおりです。
WebLogic Server 6.x で、コンピュータ リソースに対するアクセスの制御に使用されるデータ構造。アクセス制御リスト (ACL) の各エントリには、個々のユーザやユーザのグループを表す特定のプリンシパルに関連付けられた一連のパーミッションが含まれます。エントリは、肯定的なものでも否定的なものでもかまいません。パーミッションを付与するエントリが肯定的となり、パーミッションを拒否するエントリが否定的となります。WebLogic Server 7.0 以降では、ACL は非推奨になり、代わりにセキュリティ ポリシーが使用されます。引き続き ACL を使用して WebLogic リソースを保護する場合は、互換性セキュリティを使用します。「互換性セキュリティ」、「グループ」、「プリンシパル」、「セキュリティ ポリシー」、「ユーザ」、「WebLogic リソース」も参照してください。
サブジェクトが WebLogic リソースに対して特定の操作を実行するパーミッションを持っているかどうかを判定するコード。アクセス決定の結果は、許可、拒否、または決定の放棄のいずれかです。アクセス決定は、認可プロバイダのコンポーネントです。「認可プロバイダ」、「サブジェクト」、「WebLogic リソース」も参照してください。
「アクセス制御リスト (ACL)」を参照してください。
複数のアクセス決定から返される結果を調停し、アクセス決定間の衝突を解決して、PERMIT または DENY の最終判定を行う WebLogic セキュリティ プロバイダ。裁決は裁決プロバイダのコンポーネントです。「アクセス決定」、「セキュリティ プロバイダ」も参照してください。
データの暗号化と復号化に異なる鍵 (プライベート キーと公開鍵) を使用する暗号化アルゴリズムを用いる暗号方式。公開鍵で暗号化されたデータは、プライベート キーを使用することによってのみ解読できます。この非対称性によって、公開鍵暗号方式は幅広く使用されています。公開鍵暗号方式とは、非対称鍵暗号方式の別の呼び名です。「プライベート キー」、「公開鍵」、「対称鍵暗号方式」も参照してください。
否認防止を目的として、処理リクエストとその結果に関する情報を収集、格納および配布するプロセス。監査は、コンピュータのアクティビティの電子的な記録を提供します。「監査プロバイダ」も参照してください。
監査サービスを提供するセキュリティ プロバイダ。「監査」、「セキュリティ プロバイダ」も参照してください。
ユーザまたはシステム プロセスの ID を検証するためのプロセス。認証にはまた、必要に応じて、身元情報を記憶したり、転送したり、さまざまなシステム コンポーネントの利用に供する働きもあります。通常、認証はユーザ名とパスワードの組み合わせを使用して行われますが、トークンを使用することもできます。「認証プロバイダ」、「ID アサーション」、「LoginModule」、「境界認証」、「トークン」、「ユーザ」も参照してください。
ユーザを検証することで、WebLogic Server が信頼を確立することを可能にするセキュリティ プロバイダ。WebLogic Security サービス アーキテクチャは、ユーザ名とパスワードの認証、証明書に基づく認証 (WebLogic Server を直接用いる)、および HTTP 証明書に基づく認証 (外部の Web サーバを介して行う) を実行する認証プロバイダをサポートします。「認証」、「デジタル証明書」、「セキュリティ プロバイダ」、「ユーザ」も参照してください。
ユーザのセキュリティ ロールと要求された WebLogic リソースのセキュリティ ポリシーに基づいて WebLogic リソースに対するユーザのアクセスを許可または拒否するプロセス。「認可プロバイダ」、「セキュリティ ポリシー」、「ユーザ」、「WebLogic リソース」も参照してください。
ユーザのセキュリティ ロールと要求された WebLogic リソースのセキュリティ ポリシーに基づいて WebLogic リソースへのアクセスを制御するセキュリティ プロバイダ。「セキュリティ プロバイダ」、「ユーザ」、「WebLogic リソース」も参照してください。
互換性セキュリティを使用する場合にのみ、WebLogic Server 7.0 以降に適用される WebLogic Server 6.x の機能。キャッシング レルムはメモリ内の一時的な場所であり、プライマリ レルムから頻繁に呼び出される ACL、ユーザ、グループなどが格納されます。WebLogic Server 6.x では、ユーザ、グループ、および ACL のオブジェクトは filerealm.properties ファイルに格納されます。ファイルからの読み込みは非常に時間がかかる場合があります。デフォルトでは、キャッシング レルムはプライマリ レルムの上の通信層であり、ルックアップに使用されます。キャッシング レルムでのルックアップが失敗した場合、ルックアップはプライマリ レルムで実行されます。「アクセス制御リスト (ACL)」、「互換性セキュリティ」、「グループ」、「ユーザ」も参照してください。
「デジタル証明書」を参照してください。
デジタル証明書を使用することにより、サーバがクラインアントの ID を信頼するためのメソッド。証明書認証は、ユーザが知っていること (プライベート キーを保護するパスワード) に加えてユーザが持っているもの (プライベート キー) に基づいて行われるため、一般的にパスワード認証よりもよく使用されます。「認証」、「認証局」、「証明書」も参照してください。
公開鍵証明書を発行する、信頼性のあるエンティティ。認証局は、公証人と同じようにユーザの現実世界の身元を証明します。「証明書チェーン」、「デジタル証明書」、「エンティティ」、「プライベート キー」、「公開鍵」、「信頼性のある (ルート) 認証局」も参照してください。
信頼性のある認証局のプライベート キー、それに対応する公開鍵、およびデジタル証明書のチェーンを含む配列。各認証局は前のデジタル証明書の発行元です。サーバの証明書、権限、権限 2、権限 3 でチェーンが構成されている場合、サーバの証明書は権限によって署名され、権限の証明書は権限 2 によって署名され、権限 2 の証明書は権限 3 によって署名されています。これらの権限のいずれかの認証局がクライアントによって認識されると、クライアントはサーバを認証します。「信頼性のある (ルート) 認証局」も参照してください。
互換性レルムを使用している場合のデフォルト (アクティブ) セキュリティ レルムとなるセキュリティ レルム。互換性レルムでは、既存の WebLogic Server 6.x の認証プロバイダおよび認可プロバイダが使用されます。そのため、WebLogic Server 7.x 以降でそれらのプロバイダを使用できます。互換性セキュリティで使用可能なセキュリティ レルムは、互換性レルムだけです。「互換性セキュリティ」、「デフォルト レルム」、「セキュリティ プロバイダ」、「セキュリティ レルム」、「WebLogic セキュリティ プロバイダ」も参照してください。
WebLogic Server 6.x のセキュリティ コンフィグレーションをそれ以降のリリースの WebLogic Server で実行する機能。WebLogic Server 7.x 以降では互換性セキュリティを使用して、6.x のセキュリティ レルムのコンフィグレーション、ユーザ、グループ、および ACL の定義、ユーザ アカウント保護の管理、カスタム監査プロバイダのインストールを行います。互換性セキュリティで使用可能なセキュリティ レルムは、互換性レルムだけです。互換性レルムのレルム アダプタ プロバイダを使用すると、6.x セキュリティ レルムの認証および認可サービスとの下位互換性を保持できます。「アクセス制御リスト (ACL)」、「監査プロバイダ」、「互換性レルム」、「グループ」、「レルム アダプタ認証プロバイダ」、「レルム アダプタ認可プロバイダ」、「セキュリティ レルム」、「ユーザ」も参照してください。
サーバがネットワーク クライアントからの着信接続を許可するかどうかを判定するために WebLogic Server が使用するプログラミング可能なフィルタ。ユーザの特性に基づいて WebLogic リソースを保護するセキュリティ ポリシーに加えて、ネットワーク接続に基づいてフィルタ処理を行うことでセキュリティの層を追加できます。「セキュリティ ポリシー」、「ユーザ」、「WebLogic リソース」も参照してください。
「リソース アダプタ」を参照してください。
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。「セキュリティ プロバイダ」、「WebLogic コンテナ」、「WebLogic Security フレームワーク」も参照してください。
新しいサービスにアクセスするサブジェクトを認証するための情報が格納される、サブジェクトのセキュリティ関連の属性。資格のタイプには、ユーザ名とパスワードの組み合わせ、Kerberos チケット、および公開鍵証明書などがあります。「資格マッピング」、「資格マッピング プロバイダ」、「デジタル証明書」、「Kerberos チケット」、「公開鍵」、「サブジェクト」も参照してください。
対象リソースにアクセスするユーザを認証するための適切な資格群を、レガシー システムのデータベースを使用して取得するプロセス。WebLogic Server では、資格マッピングを使用して、WebLogic Server で使用される資格を、レガシー システム (またはリモート システム) で使用される資格にマップします。その後、WebLogic Server は資格マップを使用して、認証済みサブジェクトに代わってリモート システムにログインします。「資格」、「資格マッピング プロバイダ」、「リソース」も参照してください。
資格マッピング サービスを提供して、新しいタイプの資格を WebLogic Server 環境に追加するために使用されるセキュリティ プロバイダ。「資格」、「資格マッピング」、「セキュリティ プロバイダ」も参照してください。
ユーザが一度認証を行えば、複数のアプリケーションが異なる DNS ドメインにある場合でもこれらのアプリケーションにアクセスできるようになる WebLogic Server のセキュリティ機能。この機能を使用すると、シングル サインオン ドメインに参加する関連会社やパートナのネットワークを構築できます。「シングル サインオン (SSO)」も参照してください。
注意 : ドメイン間シングル サインオンは Java クライアント (つまり、Java 仮想マシン (JVM) を実行しているクライアント) に対してのみサポートされており、Web ブラウザ クライアントに対してはサポートされていません。
IIOP (GIOP 1.2) と CORBA Common Secure Interoperability バージョン 2 (CSIv2) CORBA 仕様に基づくプロトコル。EJB 2.0 およびその他の J2EE 1.4.1 コンテナの安全相互運用要件は、CSIv2 仕様の準拠レベル 0 に対応しています。CORBA Security Attribute Service (SAS) は、CSIv2 で使用されるプロトコルです。詳細については、http://www.omg.org/technology/documents/formal/omg_security.htm を参照してください。
WebLogic Security サービスに統合できる、サードパーティ セキュリティ ベンダまたはセキュリティ開発者によって記述されたセキュリティ プロバイダ。カスタム セキュリティ プロバイダは SSPI (Security Service Provider Interface) の実装であり、WebLogic Server 製品には付属していません。「セキュリティ プロバイダ」、「セキュリティ レルム」、「WebLogic セキュリティ プロバイダ」、「WebLogic Security サービス」も参照してください。
WebLogic Server 7.0 以降では、互換性セキュリティでのみサポートされるセキュリティ レルム。WebLogic Server 6.x では、独自のセキュリティ レルムを作成して WebLogic Server 環境に統合することで認証をカスタマイズします。「互換性セキュリティ」も参照してください。
セキュリティ プロバイダとそのセキュリティ プロバイダ データベースの間で行われる初期化呼び出しを仲介する中間クラス。「セキュリティ プロバイダ データベース」も参照してください。
アプリケーション デプロイメント記述子を使用して定義または宣言されるセキュリティ。Web アプリケーションの場合、web.xml ファイルおよび weblogic.xml ファイルでデプロイメント記述子を定義します。EJB の場合、ejb-jar.xml ファイルおよび weblogic-ejb-jar.xml ファイルでデプロイメント記述子を定義します。
アクティブなセキュリティ レルム。WebLogic Server 7.0 以降では、WebLogic Server ドメインに複数のセキュリティ レルムをコンフィグレーションできますが、デフォルト (アクティブ) セキュリティ レルムに指定できるのはそのうちの 1 つだけです。「カスタム セキュリティ レルム」、「セキュリティ レルム」、「WebLogic Server ドメイン」も参照してください。
特定の公開鍵と名前などの属性を関連付けるデジタル ステートメント。ステートメントは認証局によってデジタル署名されます。認証局が本物のステートメントだけに署名すると信頼することにより、公開鍵が、証明書にその名前が記された人物のものであると信頼することができます。「認証局」、「デジタル署名」、「公開鍵」、「信頼性のある (ルート) 認証局」も参照してください。
2 つのエンティティの身元を検証することで、それらのエンティティ間でやり取りされるデータのセキュリティを保護する場合に使用されるビットからなる文字列。特に、レコードの送信元エンティティからのデータが途中で変更されていないことを検証する場合に使用されます。デジタル署名は、エンティティの署名されたデータとプライベート キーから計算されます。デジタル署名による信頼は、信頼性を確認するために使用される公開鍵の範囲にとどまります。「エンティティ」、「プライベート キー」、「公開鍵」も参照してください。
WebLogic Server ドメインの新規作成を容易にする対話型グラフィカル ユーザ インタフェース (GUI)。このウィザードでは、複数のスタンドアロン サーバ、ノード マネージャを使用する管理サーバと管理対象サーバ、クラスタ化されたサーバの WebLogic Server ドメイン コンフィグレーションを作成できます。コンフィグレーション ウィザードを使用して、WebLogic Server ドメインの適切なディレクトリ構造、基本的な config.xml ファイル、およびドメイン内のサーバの起動に使用できるスクリプトを作成できます。
ユーザ、グループ、セキュリティ ロール、セキュリティ ポリシー、および資格情報が格納されるサーバ。WebLogic 認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、組み込み LDAP サーバをセキュリティ プロバイダ データベースとして使用します。「資格」、「グループ」、「セキュリティ ポリシー」、「セキュリティ ロール」も参照してください。
WebLogic Server 6.x で、ユーザ、グループ、暗号化パスワード、および ACL をファイルに格納するレルム。WebLogic Server 7.0 以降では、ファイル レルムは互換性セキュリティでのみ使用します。「互換性セキュリティ」も参照してください。
内部ネットワークとインターネットの間のトラフィックをモニタし、内部ネットワークに出入りできるネットワーク トラフィックのタイプを規制するソフトウェア。ネットワークへの不正アクセスを防ぐためにインターネットに接続されたり、企業内のネットワーク内に設定されたりします。ファイアウォールは、コンピュータに関する情報やネットワークでやり取りされる情報を保護します。ファイアウォールは、許可されるプロトコルのタイプの制限や、IP アドレスおよび DNS ノード名によるネットワーク ノードからのアクセスの制限など、さまざまなタイプのフィルタを使用してアクセスを防ぎます。
セキュリティ レルム内のすべての WebLogic リソースに適用されるセキュリティ ロール。たとえば、WebLogic ロール マッピング プロバイダがデフォルト セキュリティ レルムで使用されている場合は、ユーザ、グループ、アクセス時間に関してグローバル ロールを定義できます。「ロール マッピング プロバイダ」、「スコープ ロール」、「セキュリティ レルム」、「セキュリティ ロール」、「WebLogic リソース」も参照してください。
部署、職務、肩書きなどの特性を共有するユーザの集合。グループは、サーバ管理者が割り当てる静的な ID です。グループにはセキュリティ ロールが関連付けられます。グループにパーミッションを与えると、そのグループのメンバーである各ユーザにパーミッションを与えることになります。「ユーザ」も参照してください。
SSL 接続の接続先ホストの名前が、予定していた通信先または許可された通信先であることを検証するプロセス。「ホスト名検証」、「セキュア ソケット レイヤ (SSL)」も参照してください。
SSL 接続の接続先ホストが予定していた通信先または許可された通信先であることを検証するコード。ホスト名検証は、WebLogic Server クライアントまたは WebLogic Server インスタンスが別のアプリケーション サーバの SSL クライアントとして動作している場合に便利です。介在者の攻撃 (man-in-the-middle attack) を防ぐのに役立ちます。WebLogic Server の SSL ハンドシェーク機能としてのデフォルトの動作は、SSL サーバのデジタル証明書のサブジェクト識別名 (DN) にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。サブジェクト DN とホスト名が一致しない場合、SSL 接続は中断されます。「デジタル証明書」、「ホスト名検証」、「セキュア ソケット レイヤ (SSL)」、「サブジェクト」も参照してください。
外部ソースから生成されたトークンをクライアントが提供することでクライアントの ID を確立する特殊なタイプの認証。ID は、トークンがユーザ名にマッピングされるときに断定されます。たとえば、クライアントの ID はデジタル証明書を使用して確立することができ、その証明書をシステム内で回すことができるため、ユーザは何度もサインオンを求められることはありません。このため、ID アサーションを使用すると、シングル サインオンが可能になります。「認証」、「デジタル証明書」、「ID アサーション プロバイダ」、「シングル サインオン (SSO)」、「SSL トンネリング」、「トークン」も参照してください。
境界認証 (トークンを使用する特殊なタイプの認証) を実行するセキュリティ プロバイダ。ID アサーション プロバイダを使用しても、WebLogic Server ではユーザを検証して信頼を確立できます。したがって、ID アサーション プロバイダの機能は、トークンを検証してユーザ名にマップすることです。「境界認証」、「セキュリティ プロバイダ」、「トークン」、「ユーザ」も参照してください。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合に、ログイン シーケンスによる認証プロバイダの使用方法を決定するフラグ。「認証プロバイダ」も参照してください。
セキュリティ レルム内のユーザの認証と、サブジェクト内への必要なプリンシパルの格納を担当するモジュール。LoginModule は、認証プロバイダの必須コンポーネントであり、境界認証用に別個の LoginModule を開発する必要がある場合は ID アサーション プロバイダのコンポーネントにもなります。境界認証に使用されない LoginModule も、提示された証明データ (たとえば、ユーザのパスワード) が正しいかどうかを確認します。「認証」、「グループ」、「ID アサーション プロバイダ」、「境界認証」、「プリンシパル」、「セキュリティ レルム」、「サブジェクト」も参照してください。
認証と、ユーザのアクセス制御を可能にする Java パッケージ セット。JAAS は、標準 Pluggable Authentication Module (PAM) フレームワークの Java バージョンを実装し、ユーザベース認証をサポートします。WebLogic Server では、JAAS の認証部分のみを実装します。「認証」、「認可」、「ユーザ」も参照してください。
暗号機能のアクセスおよび開発用の Java プラットフォーム向けフレームワーク。Sun Microsystems, Inc. から提供されている Java Cryptography Architecture の詳細については、http://java.sun.com/j2se/1.4/docs/guide/security/CryptoSpec.html#Introduction を参照してください。「Java Cryptography Extensions (JCE)」も参照してください。
暗号化、鍵交換、および Message Authentication Code (MAC) アルゴリズムのための API を含めて Java Cryptography Architecture API を拡張する Java パッケージ セット。Sun Microsystems, Inc. から提供されている JCE の詳細については、http://java.sun.com/j2se/1.4/docs/guide/security/jce/
JCERefGuide.html を参照してください。「Java Cryptography Architecture」も参照してください。
Java アプリケーションにネーミング サービスを提供するアプリケーション プログラミング インタフェース (API)。JNDI は Sun Microsystems の J2EE 技術の不可欠なコンポーネントであり、特定のネーミング サービスまたはディレクトリ サービスの実装とは無関係に定義されています。JNDI では、単一の方法で、さまざまな新しいサービスや既存のサービスにアクセスできます。このサポートでは、標準サービス プロバイダ インタフェース (SPI) 規約を使用して JNDI フレームワークに任意のサービス プロバイダ実装をプラグインできます。さらに、適切なサービス プロバイダをプラグインすることで、WebLogic Server の Java アプリケーションから LDAP などの外部ディレクトリ サービスに標準化された方法でアクセスできるようになります。
Java 仮想マシン (Java virtual machine: JVM) 用のセキュリティ マネージャ。この Java セキュリティ マネージャは、Java API と連携し java.lang.SecurityManager クラスを通じてセキュリティ境界を定義するので、開発者は、自分の Java アプリケーションのカスタム セキュリティ ポリシーを設定できるようになります。
WebLogic Server で Java セキュリティ マネージャを使用して、信頼性のないコードが Java セキュリティ ポリシー ファイルによって制限されているアクションを実行しないようにできます。Java セキュリティ マネージャは、Java セキュリティ ポリシー ファイルを使用して一連のパーミッションをクラスに強制的に付与します。これらのパーミッションを使用すると、JVM のインスタンスで実行される指定されたクラスに特定の実行時処理を許可するかどうかを設定できます。「Java セキュリティ ポリシー ファイル」、「ポリシー条件」も参照してください。
WebLogic Server でサポートされている Java 仮想マシン (JVM) のインスタンスで実行される指定したクラスに、一連のパーミッションを強制的に付与するために Java セキュリティ マネージャによって使用されるファイル。JVM のインスタンスで実行されるクラスは、パーミッションを使用して特定の実行時処理を許可または拒否します。「Java セキュリティ マネージャ」、「ポリシー条件」も参照してください。
「Java Naming and Directory Interface (JNDI)」を参照してください。
物理的にセキュアでないネットワークに対するアクセスの制御に使用される数百バイトの長さのシーケンス。Kerberos チケットは Kerberos プロトコルに基づいています。Kerberos はネットワーク認証プロトコルであり、このプロトコルを使用することで、ネットワークを越えて通信を行うエンティティ (ユーザおよびサービス) は盗聴、反復などの攻撃を防ぎながら相互に身元を証明できます。このプロトコルは、秘密鍵暗号方式を使用してクライアント/サーバ アプリケーションに強力な認証を提供するために設計されました。詳細については、http://web.mit.edu/kerberos/www/ を参照してください。 「プライベート キー」も参照してください。
プライベート キーと信頼性のある認証局の組み合わせのメモリ内集合。情報は、パスワード、クレジット カード番号、暗証番号などの個人を識別する情報のパスフレーズによって保護されます。Administration Console では、キーストアは信頼キーストアと呼ばれます。詳細については、Sun Microsystems, Inc. による SDK 1.4.1 Javadoc (http://java.sun.com/j2se/1.4/docs/api/index.html) を参照してください。「プライベート キー」、「信頼性のある (ルート) 認証局」も参照してください。
Lightweight Data Access Protocol (LDAP) サーバ (iPlanet、Active Directory、Novell、OpenLDAP など) を使用してユーザおよびグループ情報にアクセスする認証プロバイダ。「グループ」、「ユーザ」も参照してください。
WebLogic Server 6.x のセキュリティ レルム。 WebLogic Server 6.x では、セキュリティ レルムは認証および認可サービスを提供します。LDAP セキュリティ レルムは、LDAP サーバを使用した認証を提供します。このサーバを使用すると、組織内のすべてのユーザを LDAP ディレクトリだけで管理できます。LDAP セキュリティ レルムは、Open LDAP、Netscape iPlanet、Microsoft Site Server、および Novell NDS をサポートしています。WebLogic Server 7.x 以降では、LDAP セキュリティ レルムは互換性セキュリティを使用している場合にのみ使用できます。「認証」、「認可」、「互換性セキュリティ」、「ファイル レルム」、「セキュリティ レルム」、「ユーザ」も参照してください。
「JAAS LoginModule」を参照してください。
管理対象 Bean (managed bean) の略で、JMX (Java Management eXtensions) で管理可能なリソースを表す Java オブジェクトのこと。MBean は、MBean タイプのインスタンスです。MBean は、セキュリティ プロバイダをコンフィグレーションおよび管理するために使用します。「MBean タイプ」、「セキュリティ プロバイダ」も参照してください。
WebLogic MBeanMaker で MBean タイプのファイルを生成するために使用される XML ファイル。「MBean タイプ」、「WebLogic MBeanMaker」も参照してください。
カスタム セキュリティ プロバイダ用の MBean タイプを作成するために WebLogic MBeanMaker ユーティリティによって生成される複数の中間 Java ファイルの 1 つ。このファイルを編集して、特定のメソッド実装を提供します。「MBean 情報ファイル」、「MBean インタフェース ファイル」、「MBean タイプ」、「WebLogic MBeanMaker」も参照してください。
カスタム セキュリティ プロバイダ用の MBean タイプを作成するために WebLogic MBeanMaker ユーティリティによって生成される複数の中間 Java ファイルの 1 つ。このファイルの大部分はメタデータなので、編集は不要です。「MBean 実装ファイル」、「MBean インタフェース ファイル」、「MBean タイプ」、「WebLogic MBeanMaker」も参照してください。
カスタム セキュリティ プロバイダ用の MBean タイプを作成するために WebLogic MBeanMaker ユーティリティによって生成される複数の中間 Java ファイルの 1 つ。このファイルは実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API であり、編集は不要です。「MBean 実装ファイル」、「MBean 情報ファイル」、「MBean タイプ」、「実行時クラス」、「WebLogic MBeanMaker」も参照してください。
セキュリティ プロバイダの実行時クラスと MBean タイプが格納される JAR ファイル。MJF は、WebLogic MBeanMaker によって作成されます。「MBean タイプ」、「実行時クラス」、「セキュリティ プロバイダ」、「WebLogic MBeanMaker」も参照してください。
セキュリティ プロバイダのコンフィグレーションと管理に使用する MBean を作成するためのファクトリ。MBean タイプは、WebLogic MBeanMaker によって作成されます。「MBean」、「セキュリティ プロバイダ」、「WebLogic MBeanMaker」も参照してください。
プレーン テキストからデジタル作成されたハッシュ (フィンガープリント)。完全なメッセージがハッシュの作成に使用されても、ハッシュからメッセージを再作成することはできません。メッセージ ダイジェストは、介在者の攻撃を防ぐのに役立ちます。特定のプレーン テキストのダイジェストは 1 つしかないので、ダイジェストをメッセージの信頼性の確認に使用できます。このため、このプロセスはメッセージのデジタル署名を生成することになります。デジタル署名を使用して否認防止サービスおよび整合性サービスを提供できます。「メッセージ ダイジェスト アルゴリズム」も参照してください。
プレーン テキストからのメッセージ ダイジェストの作成に使用される計算手順。メッセージ ダイジェストが作成されたら、他のセキュリティ メカニズムを使用してそのダイジェストを暗号化し伝達します。「メッセージ ダイジェスト」も参照してください。
サーバとクライアントの両方に ID 証明の提示を要求する認証。双方向 SSL 認証は、サーバとクライアントの両方がデジタル証明書を提示して身元を証明する相互認証の一形態です。ただし双方向 SSL 認証では SSL レベルで認証が行われる一方で、他の形態の相互認証ではプロトコル スタックのより上位のレベルで認証が実行されます。「認証」、「デジタル証明書」、「セキュア ソケット レイヤ (SSL)」、「双方向 SSL 認証」、「信頼性のある (ルート) 認証局」も参照してください。
SPNEGO (Simple and Protected Negotiate) トークンをデコードして Kerberos トークンを入手し、この Kerberos トークンを検証してシングル サインオン用に WebLogic ユーザにマップする ID アサーション プロバイダ。「SPNEGO (Simple and Protected Negotiation) メカニズム」、「デスクトップ クライアントによるシングル サインオン (SSO)」も参照してください。
サーバはクライアントに対して証明書を提示する必要があるが、クライアントはサーバに対して証明書を提示する必要がないという SSL 認証のタイプ。クライアントはサーバを認証する必要がありますが、サーバはどのクライアントの接続も受け入れます。WebLogic Server ではデフォルトで有効になっています。「相互認証」、「双方向 SSL 認証」も参照してください。
アプリケーション サーバ ドメインの外側で発生する認証。境界認証は通常、リモート ユーザが断定された ID と、検証の実行に使用される特定の形態の対応する証明データ (一般的にはパスフレーズの形態、具体的にはパスワード、クレジット カード番号、暗証番号などの個人を識別する情報) を認証サーバ (一般的には Web サーバ) に指定することによって行われます。認証サーバは、検証を実行し、アーティファクトつまりトークンをアプリケーション サーバ ドメイン (WebLogic Server ドメインなど) に渡します。アプリケーション サーバはそのトークンをドメイン内のシステムで回すことができるため、ユーザは何度もサインオンを求められることはありません。
実際に ID を保証するエンティティである、認証エージェントは、さまざまな形態を取ることができます。たとえば、仮想プライベート ネットワーク (VPN)、ファイアウォール、企業認証サービス (Web サーバ) といったグローバルな ID サービスの形態を取ることができます。
WebLogic Server のセキュリティ アーキテクチャは、境界に基づく認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティ トークン タイプとプロトコル (SOAP、IIOP-CSIv2) を処理する ID アサーション プロバイダをサポートします。「認証」、「ID アサーション」も参照してください。
セキュリティ ポリシーを作成する際の条件。ポリシー条件に対して特定の情報 (実際のユーザ名、グループ、セキュリティ ロール、開始/終了時間など) を指定したものは式と呼ばれます。「ポリシー文」も参照してください。
「ポリシー文」を参照してください。
誰に WebLogic リソースへのアクセス権が付与されるかを定義する式の集合。したがって、作成するセキュリティ ポリシーの主要部分となります。ポリシー文は、ポリシー式とも呼ばれます。「ポリシー条件」も参照してください。
認証の結果としてユーザ、グループ、またはシステム プロセスに割り当てられる ID。プリンシパルは、任意の数のユーザまたはグループで構成できます。通常、プリンシパルはサブジェクトに格納されます。「認証」、「グループ」、「サブジェクト」、「ユーザ」も参照してください。
署名し、その署名後にプリンシパルが変更されていないことを確認する行為。プリンシパル検証によってプリンシパルの信頼性が確立されます。「プリンシパル」も参照してください。
秘密のメッセージを交換する当事者だけが知っている暗号化/復号化鍵。そのオーナー以外には非公開のまま保管する必要があるので、プライベート キーと呼ばれます。「公開鍵」も参照してください。
暗号テキストをエンコード (暗号化) するために使用される計算手順。プライベート キーで暗号化されたデータは、公開鍵を使用することによってのみ解読できます。「プライベート キー」、「公開鍵」、「RDBMS セキュリティ レルム」も参照してください。
メッセージおよびデジタル署名を効果的に暗号化および解読するために使用でき、プライベート キーと結合される、暗号化鍵/解読鍵として認証局から提供される値。誰でも使用できるので、公開鍵と呼ばれます。公開鍵暗号方式は、データの暗号化と解読に異なる鍵を使用するので、非対称鍵暗号方式とも呼ばれます。「非対称鍵暗号方式」、「プライベート キー」も参照してください。
プレーン テキストをエンコード (暗号化) するために使用される計算手順。公開鍵で暗号化されたデータは、プライベート キーを使用することによってのみ解読できます。「プライベート キー」、「プライベート キー アルゴリズム」、「公開鍵」も参照してください。
「非対称鍵暗号方式」を参照してください。
WebLogic Server 6.x のセキュリティ レルム。WebLogic Server 6.x では、セキュリティ レルムで認証および認可サービスを提供していました。RDBMS セキュリティ レルムは、ユーザ、グループ、および ACL をリレーショナル データベースに保存します。WebLogic Server 7.0 以降では、RDBMS セキュリティ レルムは互換性セキュリティを使用している場合にのみ使用できます。「アクセス制御リスト (ACL)」、「認証」、「認可」、「互換性セキュリティ」、「グループ」、「セキュリティ レルム」、「ユーザ」も参照してください。
互換性セキュリティを使用するセキュリティ レルム向けに WebLogic 認可プロバイダとレルム アダプタ認可プロバイダの両方を併用できるようにする裁決プロバイダ。「互換性セキュリティ」、「互換性レルム」も参照してください。
互換性セキュリティを使用する WebLogic Server デプロイメントで weblogic.security.audit インタフェースの実装を使用できるようにする、互換性レルムの監査プロバイダ。互換性レルムとレルム アダプタ プロバイダにアクセスするには、WebLogic Server Administration Console で互換性セキュリティを実行する必要があります。「互換性セキュリティ」、「互換性レルム」も参照してください。
6.x セキュリティ レルムの認証サービスとの下位互換性を保持できるようにする互換性レルムの認証プロバイダ。互換性レルムとレルム アダプタ プロバイダにアクセスするには、WebLogic Server Administration Console で互換性セキュリティを実行する必要があります。「互換性セキュリティ」、「互換性レルム」も参照してください。
6.x セキュリティ レルムの認可サービスとの下位互換性を保持できるようにする互換性レルムの認可プロバイダ。互換性レルムとレルム アダプタ プロバイダにアクセスするには、WebLogic Server Administration Console で互換性セキュリティを実行する必要があります。「互換性セキュリティ」、「互換性レルム」も参照してください。
WebLogic Server 7.0 以降で互換性セキュリティを使用している場合に、WebLogic Server 6.x セキュリティ サービスにアクセスするために使用するセキュリティ プロバイダのタイプ。これらのプロバイダを使用することで 6.x セキュリティ プロバイダを使用できます。つまり、WebLogic Server 7.0 以降で 6.x セキュリティ プロバイダを使用できます。互換性レルムとレルム アダプタ プロバイダにアクセスするには、WebLogic Server Administration Console で互換性セキュリティを実行する必要があります。「互換性セキュリティ」、「互換性レルム」も参照してください。
「WebLogic リソース」を参照してください。
アプリケーション サーバ (WebLogic Server など) やアプリケーション クライアントで、エンタープライズ情報システム (EIS) に接続するために使用されるシステムレベルのソフトウェア ドライバ (コネクタともいう)。リソース アダプタには、Java コンポーネントに加えて、必要な場合には EIS との対話に必要なネイティブ コンポーネントが含まれます。
WebLogic J2EE コネクタ アーキテクチャは、EIS ベンダおよびサードパーティ アプリケーション開発者が開発し、Sun Microsystems の J2EE プラットフォーム仕様、バージョン 1.3 に準拠しているアプリケーション サーバにデプロイ可能なリソース アダプタをサポートしています。
セキュリティ ロール (グローバルまたはスコープ) をユーザまたはグループに付与する条件。ロール条件に対して特定の情報 (実際のユーザ名、グループ、開始/終了時間など) を指定したものは式と呼ばれます。「セキュリティ ポリシー」、「ロール マッピング」を参照してください。
ロール条件の作成時に指定する特定の情報。「ロール条件」を参照してください。
WebLogic Security サービスがセキュリティ ロール条件とユーザまたはグループを比較して、そのユーザまたはグループにセキュリティ ロールを動的に付与するかどうかを決定するプロセス。ロール マッピングは実行時に、保護対象の WebLogic リソースに対するアクセス決定を下す直前に発生します。「アクセス決定」、「グループ」、「プリンシパル」、「ロール条件」、「セキュリティ ロール」、「ユーザ」、「WebLogic リソース」、「WebLogic Security サービス」も参照してください。
WebLogic リソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ ロールを調べる、セキュリティ プロバイダ。通常、この操作では WebLogic リソースへのアクセスを取得する必要があるので、ロール マッピング プロバイダは認可プロバイダとともに使用するのが一般的です。「認可プロバイダ」、「プリンシパル」、「セキュリティ ロール」、「サブジェクト」、「WebLogic リソース」も参照してください。
セキュリティ ロールが付与される条件を定義した式の集合。したがって、作成するセキュリティ ロールの主要部分となります。「ロール式」を参照してください。
Security Service Provider Interfaces (SSPI) を実装し、セキュリティ プロバイダの実際のセキュリティ関連の動作を格納する Java クラス。「セキュリティ プロバイダ」、「Security Service Provider Interfaces (SSPI)」も参照してください。
セキュリティ レルム内の特定の WebLogic リソースに適用されるセキュリティ ロール。「グローバル ロール」、「ロール マッピング プロバイダ」、「セキュリティ ロール」、「セキュリティ レルム」も参照してください。
「対称鍵暗号方式」を参照してください。
アプリケーション間のデータのプライバシを保護するために、Netscape によって開発されたインターネット転送レベルの技術。通常、セキュア ソケット レイヤ (SSL) は、(1) 互いの ID を認証するためにアプリケーションが利用するメカニズム、および (2) アプリケーション間でやり取りするデータの暗号化を提供します。SSL では、認証用の公開鍵暗号方式、およびプライバシとデータの整合性を提供する秘密鍵暗号方式とデジタル署名の使用がサポートされています。「認証」、「デジタル署名」、「公開鍵暗号方式」、「対称鍵暗号方式」も参照してください。
セキュリティ情報をやり取りするための XML ベースのフレームワーク。SAML 実装は、相互運用性のある XML ベースのセキュリティ ソリューションを提供します。このソリューションにより、認証および認可情報のセキュアなやり取りが可能になります。SAML は、Web サービスに対してシングル サインオン機能を有効にするための主要な要素です。詳細については、http://xml.coverpages.org/saml.html を参照してください。
SAML などの異なるトークン タイプをサポートするカスタム ID アサーション プロバイダを WebLogic Server 用に開発できます。「認証」、「認可」、「ID アサーション」、「境界認証」、「ドメイン間シングル サインオン」、「ユーザ」も参照してください。
権限のないアクセスから WebLogic リソースを保護するための、WebLogic リソースとユーザ、グループ、セキュリティ ロールとの関連付け。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。セキュリティ ポリシーは、個々の WebLogic リソースか、または WebLogic リソースのコンポーネントに割り当てます。
WebLogic Server 7.0 以降では、アクセス制御リスト (ACL) に代わってセキュリティ ポリシーが使用されます (互換性セキュリティを使用する場合を除く)。「アクセス制御リスト (ACL)」、「グループ」、「セキュリティ ロール」、「ユーザ」、「WebLogic リソース」も参照してください。
WebLogic Server 7.0 以降で、アプリケーションにセキュリティ サービス (認証、認可、監査、資格マッピングなど) を提供するために、WebLogic Server セキュリティ レルムに「プラグイン」できるソフトウェア モジュール。セキュリティ プロバイダは、実行時クラスと MBean (それぞれ SSPI および MBean タイプから作成される) で構成されます。セキュリティ プロバイダは、WebLogic Server に付属している WebLogic セキュリティ プロバイダか、またはカスタム セキュリティ プロバイダです。「カスタム セキュリティ プロバイダ」、「MBean」、「MBean タイプ」、「実行時クラス」、「Security Service Provider Interfaces (SSPI)」、「WebLogic セキュリティ プロバイダ」も参照してください。
一部のセキュリティ プロバイダでセキュリティ サービスを提供するために使用される、ユーザ、グループ、セキュリティ ポリシー、ロール、および資格が格納されたデータベース。セキュリティ プロバイダ データベースとしては、(WebLogic セキュリティ プロバイダで使用されるような) 組み込み LDAP サーバ、(サンプル セキュリティ プロバイダで使用されるような) properties ファイル、またはすでに使用しているプロダクション レベルのデータベースを使用できます。「資格」、「組み込み LDAP サーバ」、「グループ」、「セキュリティ ロール」、「セキュリティ ポリシー」、「WebLogic セキュリティ プロバイダ」も参照してください。
WebLogic Server 6.x では、セキュリティ レルムは認証および認可サービスを提供します。ファイル レルムか、または Lightweight Data Access Protocol (LDAP)、Windows NT、UNIX、RDBMS レルムなどの代替セキュリティ レルムを使用します。認証をカスタマイズする場合は、独自のセキュリティ レルムを記述して WebLogic Server 環境に統合することができます。WebLogic Server 6.x では、ドメインに複数のセキュリティ レルムをコンフィグレーションできません。「ファイル レルム」も参照してください。
WebLogic Server 7.0 以降では、セキュリティ レルムはスコーピング (有効範囲の設定) メカニズムとして機能します。各セキュリティ レルムは、コンフィグレーション済みのセキュリティ プロバイダ、ユーザ、グループ、ロール、およびセキュリティ ポリシーで構成されます。単一のドメインに複数のセキュリティ レルムをコンフィグレーションできますが、デフォルト (アクティブ) セキュリティ レルムに指定できるのはそのうちの 1 つだけです。WebLogic Server には、myrealm と互換性レルムという 2 つのデフォルト セキュリティ レルムが用意されています。既存の 6.x セキュリティ コンフィグレーションには互換性レルムを介してアクセスできます。WebLogic Server 6.x では可能でしたが、アプリケーション プログラミング インタフェースを使用して独自のセキュリティ レルムを記述することはできなくなりました。代わりに、新しいセキュリティ レルム (デフォルトでは myrealm という) をコンフィグレーションして必要なセキュリティ サービスを提供し、そのセキュリティ レルムをデフォルト セキュリティ レルムに設定します。「互換性レルム」、「カスタム セキュリティ レルム」、「デフォルト レルム」、「ドメイン コンフィグレーション ウィザード」、「セキュリティ プロバイダ」、「WebLogic リソース」も参照してください。
特定の条件に基づいてユーザまたはグループに付与される、動的に計算される特権。グループとロールの違いは、グループがサーバ管理者によって割り当てられる静的な ID であるのに対し、ロールのメンバシップはユーザ名、グループ メンバシップ、時刻などのデータに基づいて動的に計算されることです。セキュリティ ロールは個々のユーザまたはグループに付与されます。また、複数のロールを使用して WebLogic リソース用のセキュリティ ポリシーを作成できます。セキュリティ ロールを作成したら、そのロールと WebLogic リソースとの関連付けを定義します。この関連付け (セキュリティ ポリシー) により、WebLogic リソースに誰がどのようにアクセスできるかが指定されます。「グローバル ロール」、「グループ」、「ロール マッピング」、「スコープ ロール」、「セキュリティ ポリシー」、「ユーザ」、「WebLogic リソース」も参照してください。
カスタム セキュリティ プロバイダを開発し、WebLogic Server Security サービスと統合できるようにする WebLogic パッケージ セット。これらのインタフェースは、WebLogic セキュリティ プロバイダおよびカスタム セキュリティ プロバイダによって実装されます。WebLogic Security フレームワークは、これらのインタフェースでメソッドを呼び出してセキュリティ操作を実行します。「セキュリティ プロバイダ」、「WebLogic Security フレームワーク」も参照してください。
Kerberos ベースのシングル サインオン (SSO) 環境への参加を可能にするメカニズム。SPNEGO プロトコルでは、HTTP で Kerberos 認証が実行され、Internet Explorer から委託資格を渡された Web アプリケーションが、ユーザに代わってそれ以降の Kerberos ベースのサービスにログインします。「ネゴシエート ID アサーション プロバイダ」、「デスクトップ クライアントによるシングル サインオン (SSO)」も参照してください。
ユーザが一度アプリケーションにサインオンすれば、他のさまざまなアプリケーション コンポーネントに (それらが独自の認証方式を使用している場合でも) アクセスできる機能。シングル サインオンは、ID アサーション、LoginModule、およびトークンを使用することで実現されます。「認証」、「ドメイン間シングル サインオン」、「ID アサーション」、「JAAS LoginModule」、「トークン」、「ユーザ」も参照してください。
Windows Active Directory 環境で認証済みのデスクトップ クライアントが、WebLogic Server で実行されている Web アプリケーションにアクセスし、その Windows Active Directory 資格でサーバに認証されるようにする機能。
デスクトップ クライアントによる SSO では、ネゴシエート ID アサーション プロバイダを使用します。このプロバイダは、SPNEGO トークンをデコードして Kerberos トークンを入手し、この Kerberos トークンを検証して WebLogic ユーザにマップします。「ネゴシエート ID アサーション プロバイダ」、「SPNEGO (Simple and Protected Negotiation) メカニズム」も参照してください。
クライアントに対する SSL のパフォーマンスを向上させるために Web スイッチに接続する、セキュア ソケット レイヤ (SSL) の周辺プラットフォーム。たとえば Alteon SSL アクセラレータを WebLogic Server で使用できます。このアクセラレータは、Web スイッチを介してクライアント (この場合は WebLogic Server) と TCP ハンドシェークを行い、セッションのすべての SSL 暗号化と解読を行います。
IP ベースのプロトコル上でセキュア ソケット レイヤ (SSL) をトンネリングすること。トンネリングとは、各 SSL レコードをカプセル化し、別のプロトコル上でレコードを送信するために必要なヘッダと一緒にパッケージ化することです。
WebLogic セキュリティ プロバイダの MBean タイプを生成するために BEA で使用するインタフェース。そのインタフェースからカスタム セキュリティ プロバイダの MBean タイプを生成できます。SSPI MBean は、コンフィグレーション上は必須であり、管理上はオプションです。「カスタム セキュリティ プロバイダ」、「MBean タイプ」、「WebLogic セキュリティ プロバイダ」も参照してください。
JAAS (Java Authentication and Authorization Service) によって指定される、個人などの単一のエンティティに対する関連情報のグループ。関連情報には、セキュリティ関連の属性 (パスワードや暗号鍵など) に加えて、サブジェクトの ID (プリンシパル) が含まれます。サブジェクトには任意の数のプリンシパルを格納できます。WebLogic Server のようなアプリケーション サーバでは、ユーザもグループもプリンシパルとして使用することができます。WebLogic セキュリティ プロバイダ (WebLogic Server 製品に付属しているセキュリティ プロバイダ) では、サブジェクトにユーザのプリンシパル (WLSUser Principal) とそのユーザがメンバーになっている各グループのプリンシパル (WLSGroups Principals) が含まれます。カスタム セキュリティ プロバイダでは ID の格納方法が異なる場合があります。「認証」、「カスタム セキュリティ プロバイダ」、「グループ」、「JAAS 制御フラグ」、「プリンシパル」、「ユーザ」も参照してください。
データの暗号化と復号化に同一の鍵を使用する暗号化アルゴリズムを採用した鍵ベースの暗号方式。対称鍵暗号方式は、秘密鍵暗号方式とも呼ばれます。「非対称鍵暗号方式」も参照してください。
ユーザまたはシステム プロセスの認証プロセスの一部として生成されるアーティファクト。ID アサーションを使用する場合は、認証を受けたユーザであることを示すトークンが提示されます。トークンには、Kerberos や SAML (Security Assertion Markup Language) など、さまざまなタイプがあります。「認証」、「Security Assertion Markup Language (SAML)」、「セキュア ソケット レイヤ (SSL)」、「ID アサーション」、「SSL トンネリング」、「Security Assertion Markup Language (SAML)」、「ユーザ」も参照してください。
ピアのデジタル証明書内での検証エラーをオーバーライドし、SSL ハンドシェークを継続することを可能にするインタフェース。また、サーバのデジタル証明書チェーンで付加的な検証を実行することで、SSL ハンドシェークを中止することもできます。
デジタル署名および公開鍵/プライベート キーの組み合わせの作成に使用されるデジタル証明書を発行する信頼性のある、周知の第三者組織または企業。信頼性のある認証局の機能は、証明書を提示する個人または組織の身元を保守する公証人の機能に似ています。信頼性のある認証局は、他の証明書に署名するために使用される証明書を発行します。認証局はルート認証局とも呼ばれます。その権限が認識されているため、その身元の検証が不要だからです。信頼性のある (ルート) 認証局 (CA) 証明書は、証明書を認証するアプリケーションにインストールされます。たとえば、Web ブラウザは通常、あらかじめインストールされた、いくつかの信頼性のある (ルート) CA 証明書とともに配布されます。サーバの証明書に署名した証明局が不明な場合に、サーバの証明書がクライアントによって必ず認証されるようにするには、周知の認証局によって署名された証明書で終了する証明書チェーンを発行することをお勧めします。「証明書チェーン」、「プライベート キー」、「公開鍵」も参照してください。
クライアントとサーバの間で接続スレッドを有効にする前に、両方に証明書の提示を要求する認証。双方向の SSL 認証では、WebLogic Server はクライアントに対して自身を認証するだけでなく (証明書認証の最低限の要件)、要求側のクライアントにも認証を要求します。クライアントは、信頼性のある認証局が発行したデジタル証明書を提出するよう要求されます。このタイプの認証は、アクセスを許可する対象を信頼性のあるクライアントに制限する場合に便利です。双方向の SSL 認証は、相互認証の一形態です。「認証」、「デジタル証明書」、「相互認証」、「セキュア ソケット レイヤ (SSL)」、「信頼性のある (ルート) 認証局」も参照してください。
WebLogic Server 6.x のセキュリティ レルム。UNIX セキュリティ レルムは小さなネイティブ プログラム (wlauth) を実行して、ユーザとグループを検索し、UNIX ログイン名とパスワードに基づいてユーザを認証します。wlauth プログラムは PAM (Pluggable Authentication Modules) を使用します。これにより、オペレーティング システムの認証サービスを、このサービスを使用するアプリケーションを変更することなくコンフィグレーションできます。WebLogic Server 7.0 以降では、UNIX セキュリティ レルムは互換性セキュリティを使用している場合にのみ使用できます。「認証」、「認可」、「互換性セキュリティ」、「グループ」、「セキュリティ レルム」も参照してください。
認証が可能なエンティティ。ユーザは、個人または Java クライアントなどのソフトウェア エンティティでもかまいません。各ユーザには、セキュリティ レルムの中で固有の ID が与えられます。セキュリティ管理を効率化するために、ユーザをグループに追加するようにしてください。グループは、通常、企業の同じ部門に所属しているなどの共通点を持つユーザの集合です。ユーザはセキュリティ ロールと関連付けられているグループに入れるか、またはセキュリティ ロールと直に関連付けることができます。「エンティティ」、「グループ」、「セキュリティ ロール」、「WebLogic リソース」も参照してください。
WebLogic Server は、サーブレット、JSP ページ、エンタープライズ JavaBean などの J2EE コンポーネント テクノロジを実装します。WebLogic Server アプリケーションを構築するには、必要に応じてこれらのサービス API を使用して、コンポーネントを作成し組み立てる必要があります。コンポーネントは、WebLogic Server の Web コンテナまたは EJB コンテナ内で実行されます。Web コンポーネントは、ブラウザ ベースの J2EE アプリケーションに対してプレゼンテーション ロジックを提供します。EJB コンポーネントは、ビジネスのオブジェクトやプロセスをカプセル化します。「WebLogic コンテナ」、「Windows NT セキュリティ レルム」も参照してください。
開発の迅速化と移植性を促進するために、J2EE ではコンポーネントで必要になる共通のサービスを識別し、コンポーネントをホストするコンテナにそれらのサービスを実装します。コンテナでは、J2EE 仕様で定義されたライフサイクルのサポートやサービスを提供しているため、構築するコンポーネントでは、下層部の詳細を扱う必要はありません。コンポーネントには作成するオブジェクトやプロセスの記述に必要なコードのみが含まれます。実行環境や、トランザクション管理、アクセス制御、ネットワーク通信、永続性メカニズムなどのサービスにアクセスするためのコードは含まれません。これらのサービスは、WebLogic Server に実装されるコンテナによって提供されます。さらに、WebLogic コンテナはアプリケーションに J2EE アプリケーション プログラミング インタフェース (API) へのアクセスを提供します。WebLogic コンテナはサーバが起動したら使用できます。このコンポーネント/コンテナの抽象化概念により、開発者は専門分野の仕事ができます。WebLogic Server には、Web コンテナと EJB コンテナという 2 種類のコンテナが用意されています。「WebLogic コンポーネント」、「Windows NT セキュリティ レルム」も参照してください。
WebLogic Server は、J2EE サービス (標準のネットワーク プロトコル、データベース システム、メッセージング システムへのアクセスなど) を実装します。WebLogic Server アプリケーションを構築するには、必要に応じてこれらのサービス API を使用して、コンポーネントを作成し組み立てる必要があります。Web アプリケーションと EJB は、JDBC、JMS (Java Messaging Service)、および JTA (Java Transaction API) などの J2EE アプリケーション サービス上に構築されています。「WebLogic コンポーネント」も参照してください。
MBean 定義ファイル (MDF) を入力とし、MBean タイプのファイルを出力するコマンドライン ユーティリティ。「MBean 定義ファイル (MDF)」、「MBean タイプ」も参照してください。
イベント、サーブレット、JDBC 接続プール、JMS 送り先、JNDI コンテキスト、接続、ソケット、ファイル、企業のアプリケーションやリソース (データベースなど) といった、WebLogic Server からアクセス可能なエンティティ。「エンティティ」も参照してください。
セキュリティの施行を統合し、他の WebLogic Server コンポーネントにセキュリティ サービスとして提供する weblogic.security.service パッケージのインタフェース。セキュリティ プロバイダは、セキュリティ サービスを必要とするアプリケーションの代わりに WebLogic Security フレームワークに働きかけます。「セキュリティ プロバイダ」も参照してください。
WebLogic Server 製品の一部として BEA によって提供されるセキュリティ プロバイダ。これらのプロバイダは、Security Service Provider Interfaces (SSPI) を使用して WebLogic Server 向けに開発されています。「カスタム セキュリティ プロバイダ」、「セキュリティ プロバイダ」、「Security Service Provider Interfaces (SSPI)」も参照してください。
セキュリティ アーキテクチャを実装する WebLogic Server サブシステム。このサブシステムは、WebLogic Security フレームワーク、Security Service Provider Interfaces (SSPI)、および WebLogic セキュリティ プロバイダという 3 つの主要なコンポーネントで構成されています。
1 つのコンフィグレーション ファイルで定義された、サーバ、サービス、インタフェース、マシン、および関連する WebLogic リソース マネージャの集合。「WebLogic リソース」も参照してください。
|
|
|