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