Oracle® Fusion Middleware

Oracle WebLogic Serverセキュリティの理解

12c (12.2.1)

E69978-02(原本部品番号:E55201-02)

2016年2月

このドキュメントでは、WebLogic Server 12.2.1のOracle WebLogicセキュリティ・サービスの基礎概念を紹介および説明します。

Oracle Fusion Middleware Oracle WebLogic Server セキュリティの理解, 12c (12.2.1)

E69978-02

Copyright © 2007, 2016, Oracle and/or its affiliatesAll rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- WebLogic Server配布キットのセキュリティ・サンプル

- ダウンロード可能な他のサンプル

- このリリースでのセキュリティの新機能と変更された機能

2 WebLogicセキュリティ・サービスの概要

- WebLogicセキュリティ・サービスの概要

- WebLogicセキュリティ・サービスの特徴

- OPSS (Oracle Platform Security Services)

- 使いやすさとカスタマイズしやすさの両立

- このリリースでの新機能と変更された機能

3 セキュリティの基礎概念

- 監査

- 認証

- サブジェクトとプリンシパル

- JAAS (Java Authentication and Authorization Service)

- JAAS LoginModules

- JAAS制御フラグ

- CallbackHandler

- 相互認証

- IDアサーション・プロバイダとLoginModule

- IDアサーションとトークン

- チャレンジIDアサーション

- サーブレット認証フィルタ

- 認証のタイプ

- ユーザー名/パスワード認証

- 証明書認証

- ダイジェスト認証

- 境界認証

- SAML (Security Assertion Markup Language)

- SAMLフレームワークの概念

- WebLogic Serverで提供されるSAMLコンポーネント

- SAMLセキュリティ・プロバイダ

- シングル・サインオン・サービス

- WebサービスでのSAML Token Profile 1.1のサポート

- シングル・サインオン(SSO)

- SAMLの使用によるWebブラウザとHTTPクライアント

- デスクトップ・クライアント

- 認可

- WebLogicリソース

- セキュリティ・ポリシー

- ContextHandler

- アクセス決定

- 裁決

- IDと信頼

- 秘密鍵

- デジタル証明書

- 認証局

- 証明書の検索と検証

- Secure Sockets Layer (SSL)

- SSLの機能

- 暗号スイート

- SSLトンネリング

- 一方向および双方向SSL認証

- SSLの構成

- ホスト名検証

- トラスト・マネージャ

- FIPSサポート

- ファイアウォール

- 接続フィルタ

- 境界認証

- Java EEとWebLogicセキュリティ

- Javaセキュリティ・パッケージ

- JSSE (Java Secure Socket Extension)

- JAAS (Java Authentication and Authorization Service)

- Javaセキュリティ・マネージャ

- Java Cryptography ArchitectureとJCE (Java Cryptography Extension)

- JACC (Java Authorization Contract for Containers)

- Java Authentication Service Provider Interface for Containers (JASPIC)

- CSIv2 (Common Secure Interoperability Version 2)

- JASPICセキュリティ

- Java Authentication Service Provider Interface for Containers (JASPIC)の概要

- JASPICプログラミング・モデル

4 セキュリティ・レルム

- セキュリティ・レルムの概要

- ユーザー

- グループ

- セキュリティ・ロール

- セキュリティ・ポリシー

- セキュリティ・プロバイダ

- セキュリティ・プロバイダ・データベース

- セキュリティ・プロバイダ・データベースとは

- セキュリティ・レルムとセキュリティ・プロバイダ・データベース

- 組込みLDAPサーバー

- RDBMSセキュリティ・ストア

- セキュリティ・プロバイダのタイプ

- 認証プロバイダ

- IDアサーション・プロバイダ

- プリンシパル検証プロバイダ

- 認可プロバイダ

- 裁決プロバイダ

- ロール・マッピング・プロバイダ

- 監査プロバイダ

- 資格証明マッピング・プロバイダ

- 証明書の検索と検証のプロバイダ

- セキュリティ・プロバイダのまとめ

- セキュリティ・プロバイダとセキュリティ・レルム

5 WebLogicセキュリティ・サービスのアーキテクチャ

- WebLogicセキュリティ・フレームワーク

- 認証プロセス

- IDアサーション・プロセス

- プリンシパル検証プロセス

- 認可プロセス

- 裁決プロセス

- ロール・マッピング・プロセス

- 監査プロセス

- 資格証明マッピング・プロセス

- 証明書の検索と検証のプロセス

- WebLogicセキュリティ・フレームワークによるシングル・サインオン

- SAML 1.1を使用したシングル・サインオン

- SAML 1.1ソース・サイトとして動作するWebLogic Server

- SAML 1.1宛先サイトとして動作するWebLogic Server

- SAML 2.0を使用したシングル・サインオン

- サービス・プロバイダ開始のシングル・サインオン

- IDプロバイダ開始のシングル・サインオン

- デスクトップSSOのプロセス

- WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

- Sender-Vouchesアサーション

- Holder-of-Keyアサーション

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- WebLogicセキュリティ・プロバイダ

- WebLogic認証プロバイダ

- その他の認証プロバイダ

- パスワード検証プロバイダ

- WebLogic IDアサーション・プロバイダ

- SAML 1.1用のSAML IDアサーション・プロバイダ

- SAML 2.0 IDアサーション・プロバイダ

- ネゴシエーションIDアサーション・プロバイダ

- WebLogicプリンシパル検証プロバイダ

- WebLogic認可プロバイダ

- WebLogic裁決プロバイダ

- WebLogicロール・マッピング・プロバイダ

- WebLogic監査プロバイダ

- WebLogic資格証明マッピング・プロバイダ

- SAML 1.1用のSAML資格証明マッピング・プロバイダ

- SAML 2.0資格証明マッピング・プロバイダ

- PKI資格証明マッピング・プロバイダ

- WebLogic証明書パス・プロバイダ

- 証明書レジストリ

- バージョン管理可能なアプリケーションのプロバイダ

用語集

はじめに

ここでは、このガイド『Oracle WebLogic Server Securityセキュリティの理解』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド『Oracle WebLogic Serverセキュリティの理解』の内容と構成について説明します。

この章の内容は次のとおりです。

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

ドキュメントのスコープ

WebLogic Serverドキュメント・セットに収められている他のセキュリティ関連ドキュメントでは特定の作業(たとえば、WebLogicセキュリティのプログラミング、カスタム・セキュリティ・プロバイダの開発、WebLogicセキュリティ・サービスの管理など)の手順をユーザーに説明しているのに対して、このドキュメントはWebLogicセキュリティ・サービスのすべてのユーザーを対象としています。そのため、このドキュメントはWebLogicセキュリティ・サービスを理解する上で基本となるものです。

注意:
WebLogicセキュリティ・サービスには、固有の用語が多数あります。「用語集」で用語を理解してから、このマニュアルをお読みください。

対象読者

このドキュメントは、以下の読者を対象としています。

- アプリケーション設計者 - セキュリティの目標を設定し、組織の全体的なセキュリティ・アーキテクチャを設計するだけでなく、WebLogic Serverのセキュリティ機能を評価して最適な実装方法を判断する設計者のことです。アプリケーション設計者は、セキュリティ・システムや最先端のセキュリティ技術とツールだけでなく、Javaプログラミング、Javaセキュリティ、およびネットワーク・セキュリティにも精通しています。

- セキュリティ開発者 - WebLogic Serverに統合するセキュリティ製品のためのシステム・アーキテクチャおよびインフラストラクチャの定義と、WebLogic Serverとともに使用するカスタム・セキュリティ・プロバイダの開発を担当する開発者です。アプリケーション設計者と連携して、セキュリティ・アーキテクチャを確実に設計に従って、セキュリティ・ホールが発生しないように実装します。また、セキュリティが確実に正しく構成されるよう、サーバー管理者とも連携します。セキュリティ開発者は、認証、認可、監査(AAA)、Java Management eXtension (JMX)などのJavaに対する深い知識、およびWebLogic Serverとセキュリティ・プロバイダの機能に対する実践的な知識をはじめとしたセキュリティ概念をしっかりと理解しています。

- アプリケーション開発者 - クライアント・アプリケーションの開発、WebアプリケーションおよびEnterprise JavaBeans (EJB)へのセキュリティ機能の付加、および他のエンジニアリング・チーム、品質保証(QA)チーム、データベース・チームとの連携によるセキュリティ機能の実装などを主な業務とするJavaプログラマのことです。アプリケーション開発者は、Java (サーブレットやJSPなどのJava Platform, Enterprise Edition (Java EE)バージョン7コンポーネントとJSEE)、およびJavaセキュリティについて実用的かつ深い知識を備えています。

- サーバー管理者 - アプリケーション設計者と密接に連携しながら、サーバーおよびサーバー上で動作するアプリケーションのセキュリティ方式の設計、潜在的なセキュリティ・リスクの特定、およびセキュリティ上の問題を防止する構成の提案を行います。関連する責務として、重要な本番システムの保守、セキュリティ・レルムの構成と管理、サーバー・リソースとアプリケーション・リソースへの認証および認可方式の実装、セキュリティ機能のアップグレード、およびセキュリティ・プロバイダのデータベースの保守などが含まれる場合もあります。サーバー管理者は、Webサービス、WebアプリケーションとEJBのセキュリティ、公開鍵セキュリティ、SSL、SAML (Security Assertion Markup Language)を含むJavaセキュリティ・アーキテクチャに関する深い知識を備えています。

- アプリケーション管理者 - サーバー管理者と共同でセキュリティ構成や、認証および認可方式を実装および管理したり、定義されたセキュリティ・レルムでデプロイされたアプリケーション・リソースへのアクセスを設定および管理したりします。アプリケーション管理者は、セキュリティの概念やJavaセキュリティ・アーキテクチャの一般的な知識を備えています。また、Java、XML、デプロイメント記述子を理解し、サーバー・ログおよび監査ログでセキュリティ・イベントを特定できます。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- 第2章「WebLogicセキュリティ・サービスの概要」では、WebLogicセキュリティ・サービスを紹介し、対象読者、主な機能、およびこのリリースでの変更点などについて説明します。

- 第3章「セキュリティの基礎概念」では、WebLogic Serverのセキュリティに関係するセキュリティ概念について説明します。このセクションでは、監査、認証、認可、Secure Sockets Layer (SSL)、ファイアウォール、Java EEとWebLogicセキュリティの関係などについて解説します。

- 第4章「セキュリティ・レルム」では、WebLogicリソースを保護するために使用するセキュリティ・レルムについて説明します。

- 第5章「WebLogicセキュリティ・サービスのアーキテクチャ」では、WebLogic Server Securityのアーキテクチャについて説明します。このセクションでは、製品の一部として含まれているWebLogicセキュリティ・フレームワーク、セキュリティ・サービス・プロバイダ・インタフェース(SSPI)、およびWebLogicセキュリティ・プロバイダについて解説します。

- 「用語集」では、WebLogic Serverセキュリティに関するドキュメントに記載されている主な用語の定義を示します。

関連情報

以下のWebLogic Serverドキュメントには、WebLogicセキュリティ・サービスに関する情報が記載されています。

- 『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』 - このドキュメントでは、WebLogic Serverのセキュリティを構成する方法について説明します。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』 - セキュリティ・ベンダーとアプリケーション開発者に対して、WebLogic Serverで使用できるカスタム・セキュリティ・プロバイダを開発するために必要な情報を提供します。

- 『Oracle WebLogic Server本番環境の保護』 - WebLogic Serverを本番環境にデプロイする前に検討すべき重要なセキュリティ対策について説明します。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 - 様々なタイプのWebLogicリソースを紹介し、WebLogic Serverを使用してそれらのリソースを保護するための情報を提供します。このドキュメントの現在のバージョンでは、URL (Web)リソースとEnterprise JavaBean (EJB)リソースのセキュリティについて重点的に説明します。

- 『Oracle WebLogic Serverのアップグレード』: バージョン6.x以前のWebLogic Serverから最新バージョンのWebLogic Serverにアップグレードするために必要な手順などの情報を提供します。また、6.xまたは以前のバージョンからアプリケーションを移行するための情報も記載されています。WebLogic Serverのアップグレード固有の情報は、『Oracle WebLogic Serverのアップグレード』を参照してください。

- Oracle WebLogic Server Java APIリファレンス: このリリースのWebLogic Serverに付属している、サポート対象のWebLogicセキュリティ・パッケージのリファレンス・ドキュメントです。

セキュリティのサンプルとチュートリアル

「関連情報」に示した情報のほかにも、様々なコード・サンプルが開発者向けに用意されています。

WebLogic Server配布キットのセキュリティ・サンプル

WebLogic Serverでは、必要に応じてEXAMPLES_HOME\examples\src\examples\securityディレクトリにあるAPIサンプル・コードをインストールできます。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを示します。(デフォルトで、EXAMPLES_HOMEはORACLE_HOME\wlserver\samples\serverに設定されています。)WebLogic Serverのサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとサンプル・コードに関する項を参照してください。

WebLogicのセキュリティ機能については、次のサンプルを参照してください。

- Java認証および認可サービス

- 発信および双方向SSL

ダウンロード可能な他のサンプル

APIのその他のサンプルは、http://www.oracle.com/technetwork/indexes/samplecode/index.htmlでダウンロードできます。これらのサンプルは、WebLogic Serverの既存のサンプル・ディレクトリ構造に解凍できる.zipファイルで配布されます。

ダウンロード可能なサンプルの構築と実行方法は、インストールされているWebLogic Serverのサンプルと同様です。詳細は、各サンプルのダウンロード・ページを参照してください。

このリリースでのセキュリティの新機能と変更された機能

WebLogic Serverのこのリリースに追加された新機能の一覧については、「Oracle WebLogic Serverの新機能」 12.2.1を参照してください。

2 WebLogicセキュリティ・サービスの概要

この章では、WebLogicセキュリティ・サービスとその機能について説明します。

この章の内容は次のとおりです。

- WebLogicセキュリティ・サービスの概要

- WebLogicセキュリティ・サービスの特徴

- OPSS (Oracle Platform Security Services)

- 使いやすさとカスタマイズしやすさの両立

- このリリースでの新機能と変更された機能

WebLogicセキュリティ・サービスの概要

セキュリティのデプロイメント、管理、および保守は、Webを使用する顧客に対して新しい様々なサービスを提供しているIT (情報技術)企業にとって大きな課題です。IT企業は、Webベースのユーザーに世界規模のネットワークを提供できるよう、システムとそのデータの機密性、整合性、および可用性の保持という基本的な問題に取り組まなければなりません。セキュリティに対する取組みは、ネットワーク自体から個々のクライアント・マシンに至るまで、システムのすべてのコンポーネントに関係します。インフラストラクチャ全体のセキュリティの実現は、確立されたセキュリティ・ポリシーと周知徹底された手順に加え、不断の警戒が要求される大変な作業です。

WebLogic Serverには、Webを介して使用できるアプリケーション用に一意でセキュアな基盤を提供するセキュリティ・アーキテクチャが含まれています。企業は、WebLogic Serverのセキュリティ機能を利用することで、Web上で使用できるアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ・インフラストラクチャのメリットを得ることができます。WebLogicセキュリティは、WebLogic Serverアプリケーションを保護するためにスタンドアロンで使用することも、最高レベルのセキュリティ管理ソリューションを表す企業全体のセキュリティ管理システムの一部として使用することもできます。

WebLogicセキュリティ・サービスの特徴

WebLogic Serverのセキュリティ・アーキテクチャはオープンで柔軟性が高いため、すべてのレベルのユーザーが利点を生かすことができ、アプリケーション・サーバーに対して高度なセキュリティ設計を導入できます。アプリケーション・サーバーの一意のセキュリティ・ソリューション、および明確なセキュリティ・ポリシーとドキュメントで確立された手順を有している企業であれば、サーバーとそのデータの機密性、整合性、および可用性を確保できます。

WebLogicセキュリティ・サービスの主な特徴は、以下のとおりです。

- 包括的な標準ベースの設計。

- メインフレームからWebブラウザまでを網羅する、WebLogic Serverをホストとしたアプリケーション向けのエンドツーエンド・セキュリティ。

- レガシー・セキュリティ方式をWebLogic Serverセキュリティに統合することによって、企業の既存投資を活用できます。

- 融通性の高い統一されたシステムに組み込まれ、企業全体にわたるセキュリティ管理を容易化するセキュリティ・ツール。

- 企業のビジネス・ルールをセキュリティ・ポリシーにマッピングするため、ビジネス要件に対するアプリケーション・セキュリティのカスタマイズが容易です。

- Java EEリソースおよびアプリケーション定義のリソースに、同じモデルに従ってセキュリティ・ポリシーを適用できます。

- セキュリティ・ポリシーの容易な更新。このリリースでは、セキュリティ・ポリシーだけでなく、WebLogicリソースへのアクセスを制御する式の作成が、より容易に行えるようになっています。

- カスタマイズされたセキュリティ・ソリューションへの適合が容易です。

- モジュール化されたアーキテクチャなので、特定の企業の要件を満たすようにセキュリティ・インフラストラクチャを時間を追って変更できます。

- 遷移方式またはアップグレード・パスの一部として、複数のセキュリティ・プロバイダの構成をサポート。

- セキュリティの詳細とアプリケーション・インフラストラクチャを分離することにより、要件の変化に合わせたセキュリティのデプロイ、管理、維持、および修正を容易化。

- 即時利用可能な実践的セキュリティ方式を提供する、デフォルトのWebLogicセキュリティ・プロバイダ。このリリースでは、その他の認証ストア(データベースなど)をサポートし、選択したセキュリティ・プロバイダによって使用されるデータ・ストアとして、外部RDBMSシステムを構成することができます。

- カスタム・セキュリティ・プロバイダを使用したセキュリティ・スキームのカスタマイズ。

- WebLogic Server管理コンソールを使用して、セキュリティ・ルール、セキュリティ・ポリシー、およびセキュリティ・プロバイダを統一して管理できます。

- JAAS (Java Authentication and Authorization Service)、JSSE (Java Secure Socket Extension)、JCE (Java Cryptography Extension)、JASPIC (Java Authentication Service Provider Interface for Containers)、JACC (Java Authorization Contract for Containers)などの標準のJava EEセキュリティ技術をサポート。

- SAML (Security Assertion Markup Language) 1.1および2.0のサポートを含む、Webサービス・セキュリティの基盤。

- Webサイト、Webアプリケーション、デスクトップ・クライアントでのシングル・サインオン(SSO)にWebLogic Serverを参加させることが可能です。

- 証明書の検索、検証、失効だけでなく証明書レジストリも含む公開鍵管理のためのフレームワーク。

OPSS (Oracle Platform Security Services)

OPSS (Oracle Platform Security Services)を使用することで、エンタープライズ製品開発チーム、システム・インテグレータ(SI)、および独立系ソフトウェア・ベンダー(ISV)は、標準ベースで移植可能なエンタープライズ・レベルの統合セキュリティ・フレームワークに基づいて、Java Standard Edition (Java SE)アプリケーションおよびJava Enterprise Edition (Java EE)アプリケーションを開発できます。

OPSSでは、標準ベースのアプリケーション・プログラミング・インタフェース(API)の形式で抽象化レイヤーが提供されているため、開発者はセキュリティやID管理の実装についての詳細を意識する必要がありません。OPSSを使用すれば、開発者は、暗号鍵管理や、ユーザー・リポジトリおよびその他のID管理インフラストラクチャとの相互作用について詳しく理解する必要はありません。OPSSを使用することで、自社開発のアプリケーション、サード・パーティ製のアプリケーション、および統合アプリケーションはすべて、企業全体で同じ共通のセキュリティ、ID管理、および監査サービスを使用できるようになります。

OPSSはWebLogic Serverのコンポーネントではなく、スタンドアロンWebLogic Serverインストールでは使用できません。OPSSはOracle Fusion Middlewareインフラストラクチャ・ソフトウェアから使用でき、Oracle JRFテンプレートに基づく、またはOracle JRFテンプレートで拡張されたドメイン内のWebLogic Serverで使用されます。詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。Oracle JRFドメイン・テンプレートの詳細は、『ドメイン・テンプレート・リファレンス』のOracle JRFテンプレートに関する項を参照してください。

OPSSの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

使いやすさとカスタマイズしやすさの両立

WebLogicセキュリティ・サービスのコンポーネントおよびサービスでは、エンド・ユーザーと管理者による使いやすさと管理しやすさ、およびアプリケーション開発者とセキュリティ開発者によるカスタマイズしやすさの両立が求められます。以下の節で、いくつか例を示します。

使いやすい: WebLogic Serverには、ドメイン構成ウィザードが用意されています。ドメイン構成ウィザードは、管理サーバー、管理対象サーバー、および必要に応じてクラスタを含む新しいドメインの作成と、個々のサーバーを追加することによる既存のドメインの拡張を支援します。また、ドメイン構成ウィザードは、新しいドメインに追加することを選択したサーバー用のconfig.xmlファイルおよび開始スクリプトを自動的に生成します。

管理しやすい: WebLogic Server環境でアプリケーションを構成およびデプロイする管理者は、製品に付属しているWebLogicセキュリティ・プロバイダを使用できます。これらのデフォルトのプロバイダは、即時利用可能な状態で、必要なすべてのセキュリティ機能をサポートしています。管理者は、WebLogic Serverに用意されているセキュリティ・ストア(特殊用途の組込みLDAPディレクトリ・サーバー)にセキュリティ・データを格納したり、外部LDAPサーバー、データベース、またはユーザー・ソースを使用したりできます。WebLogic Serverのセキュリティの構成と管理を簡素化するために、堅牢なデフォルトのセキュリティ構成が用意されています。

カスタマイズしやすい: アプリケーション開発者に対しては、WebLogicセキュリティAPIと、JAAS、JSS、JCE、JACCなどのJava EEセキュリティ標準がサポートされています。これらのAPIと標準を使用して、WebLogic Serverに接続するアプリケーションに対して、きめ細かい、カスタマイズされたセキュリティ環境を作成できます。

セキュリティ開発者は、セキュリティ・サービス・プロバイダ・インタフェース(SSPI)を使用して、WebLogic Server環境向けのカスタム・セキュリティ・プロバイダを開発できます。

このリリースでの新機能と変更された機能

このリリースの新機能と変更された機能については、『Oracle WebLogic Serverの新機能』 12.2.1を参照してください。

3 セキュリティの基礎概念

この章では、WebLogic Serverのセキュリティに関係するセキュリティの基本概念について説明します。

この章の内容は次のとおりです。

- 監査

- 認証

- SAML (Security Assertion Markup Language)

- シングル・サインオン(SSO)

- 認可

- IDと信頼

- Secure Sockets Layer (SSL)

- ファイアウォール

- Java EEとWebLogicセキュリティ

- JASPICセキュリティ

監査

監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査はコンピュータのアクティビティの電子的な記録を提供するものです。WebLogic Serverのセキュリティ・アーキテクチャでは、監査プロバイダを使用して監査サービスを提供します。

監査プロバイダが構成されている場合、ドメイン構成に変更が加えられるか、ドメイン内のいずれかのリソースで管理操作が呼び出されると、セキュリティ操作(認証や認可など)が実行される前とされた後に、WebLogicセキュリティ・フレームワークが監査プロバイダを呼び出します。個々のイベントを監査するかどうかの決定は監査プロバイダによって行われ、特定の監査基準または重大度レベルあるいはその両方に基づいて決定することができます。監査情報を記載した記録は、LDAPサーバー、データベース、シンプル・ファイルなどの出力リポジトリに書き出すことができます。

認証

認証とは、呼出し側が、特定のユーザーまたはシステムのかわりに動作していることを証明する際に使用するメカニズムのことです。認証は、ユーザー名とパスワードの組合せなどの資格証明を使用して「あなたは誰」という問いに答えます。

WebLogic Serverでは、ユーザーまたはシステム・プロセスのIDを証明するために認証プロバイダを使用します。認証プロバイダでは、ID情報を記憶したり、トランスポートしたり、その情報が必要な場合に(サブジェクトを通じて)システムの様々なコンポーネントで利用できるようにしたりします。認証プロセスでは、プリンシパル検証プロバイダが、サブジェクト内に格納されるプリンシパル(ユーザーおよびグループ)のセキュリティを強化するため、それらのプリンシパルに署名して信頼性を検証します。

以下の節では、認証の概念と機能について説明します。

- サブジェクトとプリンシパル

- JAAS (Java Authentication and Authorization Service)

- CallbackHandler

- 相互認証

- サーブレット認証フィルタ

- IDアサーション・プロバイダとLoginModule

- IDアサーションとトークン

- 認証のタイプ

注意:
Java Authentication Service Provider Interface for Containers (JASPIC)を認証に使用する方法については、「JASPICセキュリティ」を参照してください。

サブジェクトとプリンシパル

サブジェクトとプリンシパルは密接に関係しています。

プリンシパルは、認証の結果としてユーザーまたはグループに割り当てられるIDです。WebLogic Serverのようなアプリケーション・サーバーでは、ユーザーもグループもプリンシパルとして使用することができます。JAAS (Java Authentication and Authorization Service)では、プリンシパルなどの認証情報のコンテナとしてサブジェクトを使用することになっています。

図3-1に、ユーザー、グループ、プリンシパル、およびサブジェクト間の関係を示します。

図3-1 ユーザー、グループ、プリンシパル、およびサブジェクトの間の関係

認証に成功すると、その一環として、プリンシパルは署名され、その後の使用に備えてサブジェクトに格納されます。プリンシパルに署名するのはプリンシパル検証プロバイダであり、実際にプリンシパルをサブジェクトに格納するのはLoginModuleです。後で、サブジェクト内に格納されたプリンシパルに呼出し側がアクセスしようとすると、そのプリンシパルが署名されてから変更されていないことをプリンシパル検証プロバイダが確認したうえで、そのプリンシパルが呼出し側に返されます(それ以外のセキュリティ条件がすべて満たされている場合)。

WebLogic Serverユーザーまたはグループを表すプリンシパルは、weblogic.security.spiパッケージのWLSUserインタフェースとWLSGroupインタフェースを実装する必要があります。

JAAS (Java Authentication and Authorization Service)

クライアントが認証の必要なアプリケーション、アプレット、Enterprise JavaBean (EJB)、あるいはサーブレットのいずれであろうと、WebLogic Serverでは、JAAS (Java Authentication and Authorization Service)クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。JAASは、プラガブル認証モジュール(PAM)フレームワークのJavaバージョンを実装します。このフレームワークにより、アプリケーションは基底の認証技術から独立することができます。このため、PAMフレームワークを利用することで、アプリケーションに修正を加えることなく新しいまたは更新された認証技術を使用することができます。

WebLogic Serverは、リモートのファット・クライアントの認証および内部の認証でJAASを使用します。したがって、JAASに直に関与する必要があるのは、カスタム認証プロバイダの開発者とリモート・ファット・クライアント・アプリケーションの開発者だけです。シン・クライアントのユーザーまたはコンテナ内のファット・クライアント・アプリケーション(サーブレットからEnterprise JavaBeanを呼び出すものなど)の開発者は、JAASを直接使用したり、その知識を身につけたりする必要はありません。

JAAS LoginModule

LoginModuleは、認証処理における「馬車馬」のような存在です。すべてのLoginModuleは、セキュリティ・レルム内のユーザーの認証と、サブジェクト内への必要なプリンシパル(ユーザー/グループ)の格納を担当します。境界認証に使用されないLoginModuleも、提示された証明情報(たとえば、ユーザーのパスワード)が正しいかどうかを確認します。

セキュリティ・レルムに複数の認証プロバイダが構成されている場合、各認証プロバイダのLoginModuleは同じサブジェクトにプリンシパルを格納します。したがって、ある認証プロバイダのLoginModuleによって、WebLogic Serverユーザー(WLSUserインタフェースの実装)を表すプリンシパル「Joe」が追加された場合、セキュリティ・レルム内の他のすべての認証プロバイダは、「Joe」に出会ったときに同じ人物を参照する必要があります。つまり、他の認証プロバイダのLoginModuleは、同じ人物を参照するために、WebLogic Serverユーザーを表す別のプリンシパル(「Joseph」など)をサブジェクトに追加しようとしてはなりません。ただし、別の認証プロバイダのLoginModuleは、WLSUser以外のタイプのプリンシパルを「Joseph」という名前で追加することができます。

JAAS制御フラグ

セキュリティ・レルムに複数の認証プロバイダが構成されている場合、認証プロバイダの制御フラグ属性で認証プロバイダの実行順序を決定します。次に、制御フラグ属性の値を示します。

- REQUIRED - このLoginModuleは成功する必要があります。失敗しても、認証は構成されている認証プロバイダのLoginModuleリストにある次のLoginModuleに進みます。これはデフォルト設定です。

- REQUISITE - このLoginModuleは成功する必要があります。他の認証プロバイダが構成されている場合、このLoginModuleが成功すると、認証はLoginModuleリストにある次のLoginModuleに進みます。それ以外の場合、制御はアプリケーションに戻されます。

- SUFFICIENT - このLoginModuleは成功する必要はありません。成功した場合、制御はアプリケーションに戻されます。他の認証プロバイダが構成されている場合、このLoginModuleが失敗すると、認証はLoginModuleリストにある次のLoginModuleに進みます。

- OPTIONAL - ユーザーはこの認証プロバイダの認証テストを通過することも失敗することもできます。ただし、セキュリティ・レルムで構成されているすべての認証プロバイダでJAASの「制御フラグ」属性が「OPTIONAL」に設定されている場合、ユーザーは構成済みプロバイダのいずれかの認証テストを通過する必要があります。

CallbackHandler

CallbackHandlerは、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟なJAAS規格です。CallbackHandlerのタイプは、NameCallback、PasswordCallback、およびTextInputCallbackの3つで、いずれもjavax.security.auth.callbackパッケージに収められています。NameCallbackとPasswordCallbackは、それぞれユーザー名とパスワードを返します。TextInputCallbackは、ユーザーがログイン・フォームの追加フィールド(ユーザー名とパスワードを取得するフィールド以外のフィールド)に入力したデータにアクセスするために使用します。TextInputCallbackはフォームの追加フィールドにつき1つ必要で、各TextInputCallbackのプロンプト文字列はフォームのフィールド名と一致する必要があります。WebLogic Serverは、フォームベースのWebアプリケーション・ログインに対してのみTextInputCallbackを使用します。

アプリケーションは、CallbackHandlerを実装し、それを基底のセキュリティ・サービスに渡すことで、それらのサービスがアプリケーションと対話してユーザー名やパスワードなど特定の認証データを取得したり、エラーや警告メッセージなど特定の情報を表示したりできるようにします。

CallbackHandlerは、アプリケーションに依存する形で実装されます。たとえば、グラフィカル・ユーザー・インタフェース(GUI)を持つアプリケーションに対する実装では、ウィンドウを表示してリクエストされた情報をプロンプトしたり、エラー・メッセージを表示したりできます。リクエストされた情報をユーザーからではなく、代替ソースから取得するように実装することもできます。

基底のセキュリティ・サービスは、個々のCallbacksをCallbackHandlerに渡すことによって様々なタイプの情報に対するリクエストを行います。CallbackHandler実装は、渡されたCallbacksに応じて情報を取得したり表示したりする方法を決定します。たとえば、基底のサービスがユーザーを認証するためにユーザー名とパスワードを必要としていれば、NameCallbackおよびPasswordCallbackを使用します。その後、CallbackHandlerは逐次的にユーザー名およびパスワードの入力を求めるか、または単一のウィンドウで両方の入力を求めるかを選択できます。

相互認証

相互認証を使用すると、クライアントとサーバーの両方で相互に認証が必要になります。この認証は、証明書などの形態の証明データを使用して行うことができます。WebLogic Serverでは、相互認証の一形態である、双方向のSSL認証がサポートされています。ただし厳密には、相互認証はSSL認証よりも上位のプロトコル・スタックで行われます。詳細については、「一方向および双方向SSL認証」を参照してください。

IDアサーション・プロバイダとLoginModule

LoginModuleと一緒に用いると、IDアサーション・プロバイダはシングル・サインオンをサポートします。たとえば、IDアサーション・プロバイダはSAMLアサーションを処理できるため、ユーザーがサインオンを複数回求められることはありません。

IDアサーション・プロバイダが使用するLoginModuleでは、以下のことが可能です。

- 開発したカスタム認証プロバイダの一部となります。

- Oracleが開発してWebLogic Serverと一緒にパッケージ化したWebLogic認証プロバイダの一部となります。

- サード・パーティのセキュリティ・ベンダーの認証プロバイダの一部となります。

単純認証の場合と違って、IDアサーション・プロバイダが使用するLoginModuleは証明データ(ユーザー名とパスワードなど)を検証しません。単にユーザーが存在することを検証するだけです。

IDアサーションとトークン

IDアサーション・プロバイダでは、有効なトークンをWebLogic Serverユーザーにマップする、ユーザー名マッパーがサポートされています。IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスのIDをアサートするために使用する特定のトークン・タイプをサポートするために開発します。IDアサーション・プロバイダは複数のトークン・タイプをサポートするように開発できますが、WebLogic Server管理者はただ1つの「アクティブ」なトークン・タイプを検証するようにIDアサーション・プロバイダを構成する必要があります。同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを1つのセキュリティ・レルムに組み込むことも可能ですが、実際に検証を行うのは1つのIDアサーション・プロバイダだけです。

注意:
X.501およびX.509証明書に対してWebLogic IDアサーション・プロバイダを使用するには、WebLogic Server製品に付属のデフォルトのユーザー名マッパー(weblogic.security.providers.authentication. DefaultUserNameMapperImpl)を使用するか、独自のweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を使用するかのいずれかの方法があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタムIDアサーション・プロバイダを開発する必要があるか」を参照してください。

チャレンジIDアサーション

チャレンジIDアサーション・スキームにより、複数のチャレンジ、レスポンス・メッセージ、および状態が規定されます。WebLogic Serverのセキュリティ・レルムには、MicrosoftのWindows NTチャレンジ/レスポンス(NTLM)、SPNEGO (Simple and Protected GSS-API Negotiation)、その他のチャレンジ/レスポンス認証メカニズムなどの認証プロトコルをサポートするセキュリティ・プロバイダを設定できます。WebLogic Serverには、ネゴシエーションIDアサーション・プロバイダというSPNEGOセキュリティ・プロバイダが付属しています。NTLMや他のチャレンジ/レスポンス認証メカニズムを実装するセキュリティ・プロバイダを開発してデプロイすることも可能です。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

サーブレット認証フィルタ

JavaサーブレットAPI仕様で定義されているように、フィルタはリクエストや応答を変更できるオブジェクトです。フィルタは、リクエストがサーブレットに届く前のプリプロセッサ、またはサーブレットから離れたレスポンスのポストプロセッサとして機能します。フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化できます。

フィルタは、コンテナ・ベースの認証のかわりとして使用できますが、この設計にはいくつかの欠点があります。

- JavaサーブレットAPI仕様で指定されているように、フィルタは認証と認可の後に実行されます。認証にフィルタを使用する場合は、コンテナ管理の認可が使用されないようにするため、認可にもフィルタを使用する必要があります。サーブレット・コンテナでの認証処理で拡張機能が必要になるほとんどのケースでも、認可処理には拡張機能が必要とされません。フィルタに認可処理を実装しなければならないのは、煩雑で時間もかかり、間違いも発生しやすくなります。

- Java EEフィルタは、Webアプリケーションごとに定義されます。フィルタのコードはWebアプリケーションのWARファイルに格納する必要があり、構成はweb.xmlファイルで定義しなければなりません。通常、認証メカニズムは、アプリケーションの記述後にシステム管理者が決定します。WARファイルを作成したプログラマが決定するわけではありません。このメカニズムは、アプリケーションの存続期間に変更でき、サイト内のすべての(少なくともほとんどの)アプリケーションで必要になります。

サーブレット認証フィルタは、これらの欠点を克服してコンテナ・ベースの認証のかわりに使用できるようにしたフィルタ・オブジェクトの拡張です。

WebLogic認証プロバイダ内のJAAS LoginModuleは、ログイン・プロセスのカスタマイズに使用できます。サーブレット認証フィルタでLoginModuleモデルを有効にすることで、認証プロバイダがクライアントとの実際の会話を制御できます。ユーザー・データベースの場所のカスタマイズ、ログインの実行に必要な証明データの種類、サブジェクトへのグループの指定は、LoginModuleを介して実装されます。一方、ログインを実行するためのリモート・サイトへのリダイレクト、問合せ文字列からのログイン情報の抽出、ブラウザとのログイン機能のネゴシエーションは、サーブレット認証フィルタを介して実装されます。

認証のタイプ

WebLogic Serverユーザーが、保護されているWebLogicリソースへのアクセスをリクエストする場合、必ず認証を受けなければなりません。このため、各ユーザーは資格証明(パスワードなど)をWebLogic Serverに提示する必要があります。WebLogic Server配布キットに含まれているWebLogic認証プロバイダでは、以下のタイプの認証がサポートされています。

- ユーザー名/パスワード認証

- 証明書認証

- ダイジェスト認証

- 境界認証

WebLogic Serverでは、WebLogic Server製品の一部として提供されるWebLogic認証プロバイダ、または様々なタイプの認証を実行するカスタム・セキュリティ・プロバイダを使用できます。WebLogic認証プロバイダと認証の構成方法の詳細は、「認証プロセス」および『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』の次の項を参照してください。

- WebLogicセキュリティ・プロバイダの構成

- SSLの構成

ユーザー名/パスワード認証

ユーザー名/パスワード認証では、ユーザーIDとパスワードをユーザーにリクエストし、WebLogic Serverに送ります。WebLogic Serverは受け取った情報をチェックして、信頼性を確認できれば、保護されているWebLogicリソースへのアクセスを許可します。

Secure Sockets Layer (SSL)、またはHyper-Text Transfer Protocol (HTTPS)を使用すると、ユーザー名/パスワード認証にさらに高度なレベルのセキュリティを提供できます。SSLは、クライアントとWebLogic Serverとの間で転送されるデータを暗号化するので、ユーザーIDとパスワードはクリア・テキストでは転送されません。したがって、WebLogic Serverは、ユーザーのIDおよびパスワードの機密性を保持したままユーザーを認証できます。

証明書認証

SSLまたはHTTPSクライアントのリクエストが送信されると、WebLogic Serverは、クライアントに対してデジタル証明書を提示して応答します。クライアントによってそのデジタル証明書が確認されると、SSL接続が確立されます。デジタル証明書は、WebLogic Serverの身元を検証するエンティティ(信頼性のある認証局)によって発行されます。

相互認証の一形態である、双方向のSSL認証を使用することもできます。双方向のSSL認証では、クライアントとサーバーの両方が証明書を提示しないと、両者の間で接続スレッドが有効になりません。「一方向および双方向SSL認証」を参照してください。

注意:
双方向のSSL認証は、WebLogic Server製品の一部として提供されるWebLogic認証プロバイダでサポートされています。

ダイジェスト認証

ダイジェスト認証を使用すると、Webサービスのセキュリティ・パスワード・ダイジェストのサポートに必要なパスワード情報を格納できます。

ダイジェスト認証を使用している場合、クライアントがサーバーに対して未認証のリクエストを行うと、サーバーはダイジェスト認証をサポートしていることを示すダイジェスト認証チャレンジを含むレスポンスを送信します。クライアントはnonceを生成し、タイムスタンプ、ダイジェスト、およびユーザー名とともにサーバーに送信します。ダイジェストは、パスワード、nonce、およびタイムスタンプの暗号ハッシュです。クライアントは、ユーザー名と、パスワードにnonce値を組み合せた暗号ハッシュを送信して、リソースを再度リクエストします。サーバーはハッシュ自体を生成し、生成されたハッシュがリクエスト内のハッシュと一致していればリクエストを許可します。

ダイジェスト認証の利点は、リプレイ攻撃に対する抵抗力です。ダイジェスト認証を実装すると、使用されたnonce/タイムスタンプのキャッシュが、指定した期間保持されます。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonceペアと同じタイムスタンプ/nonceペアを使用するリクエストもすべて拒否されます。WebLogic Serverでは、このキャッシュはデータベースに格納されます。

境界認証

境界認証は、アプリケーション・サーバー・ドメインの外側にいるリモート・ユーザーのIDを認証するプロセスです。

以下の節では、境界認証について説明します。

- 境界認証の仕組み

- WebLogic Serverが境界認証をサポートする仕組み

境界認証の仕組み

境界認証は通常、リモート・ユーザーがアサートされたIDと、検証の実行に使用される特定の形態の対応する証明データ(一般的にはパスフレーズの形態、具体的にはパスワード、クレジット・カード番号、暗証番号などの個人を識別する情報)を指定することによって行われます。

実際にIDを保証するエンティティである、認証エージェントは、さまざまな形態を取ることができます。たとえば、仮想プライベート・ネットワーク(VPN)、ファイアウォール、企業認証サービスといったグローバルなIDサービスの形態を取ることができます。認証エージェントのこれらの形態には共通の特徴があります。これらはすべて、認証を受けたユーザーに関する情報を調べるために後で提示する必要があるアーティファクトつまりトークンを生成するという認証プロセスを実行します。現時点では、トークンの形式はベンダーごとに異なりますが、XMLを使用した標準のトークン形式の定義が進められています。さらに、属性証明書に対しては、デジタル証明書用のX.509標準に基づいた標準があります。しかし、結局のところ、アプリケーションやそれが構築されているインフラストラクチャがこの概念をサポートするよう設計されていない場合は、企業のネットワーク内のアプリケーションに対してリモート・ユーザーは再認証を行う必要があります。

WebLogic Serverが境界認証をサポートする仕組み

WebLogic Serverは、IDアサーションのサポートを介して境界までシングル・サインオン概念を拡張できるよう設計されています(図3-2を参照)。WebLogicセキュリティ・フレームワークの重要な部分として提供されるIDアサーションの概念により、SAML (Security Assertion Markup Language)、SPNEGO (Simple and Protected GSS-API Negotiation)、またはCSI (Common Secure Interoperability) v2を始めとするプロトコルへの拡張など、境界認証方式によって提供される認証メカニズムを使用してWebLogic Serverでこの機能を実現できます。

図3-2 境界認証

境界認証をサポートするには、1つまたは複数のトークン・フォーマットをサポートするように設計されたIDアサーション・プロバイダを使用する必要があります。複数の異なるIDアサーション・プロバイダを登録して使用できます。トークンは、WebLogic Serverがサポートするさまざまなプロトコルによって提供されるメカニズムを使用して、通常のビジネス・リクエストの一部として転送されます。WebLogic Serverでリクエストが受け取られると、プロトコル・メッセージを処理するエンティティによってメッセージ内のトークンが認識されます。この情報は、WebLogicセキュリティ・フレームワークの呼出しに使用されます。WebLogicセキュリティ・フレームワークは、トークンの検証を処理する適切なIDアサーション・プロバイダを呼び出します。トークンを検証し、そのトークンの信頼性を確立するために必要なすべてのアクションの実行と、保証されたユーザーIDの提供は、IDアサーション・プロバイダ実装によって行われます。ユーザーはアプリケーションに対して再認証を行う必要がありません。

SAML (Security Assertion Markup Language)

SAML標準は、Web上のソフトウェア・エンティティの間でセキュリティ・アサーションを作成、リクエスト、交換するための共通XMLフレームワークを定義します。このフレームワークには、SAMLアサーションおよびプロトコルの使用して次の操作を実現する方法が規定されています。

- オンライン・ビジネス・パートナ間のブラウザ・ベースのシングル・サインオン(SSO)

- Webサービス・セキュリティのID情報の交換

SAMLは、OASIS (Organization for the Advancement of Structured Information Standards)によって開発され、このリリースのWebLogic Serverでは、以下のサポートを含むSAML 1.1および2.0を幅広くサポートしています。

- SAML Web SSOプロファイル
SAML Web SSOプロファイルには、IDプロバイダ(アサーションのプロデューサ)とサービス・プロバイダ(アサーションのコンシューマ)間において、SAMLアサーションおよびプロトコルを使用してブラウザ・ベースのシングル・サインオンを実現する方法が規定されています。

SAML 2.0 Web SSOプロファイルでは、Webユーザーはサービス・プロバイダ・サイトによってホストされるリソースを呼び出すか、結果的にサービス・プロバイダによってホストされるリソースが呼び出される方法でIDプロバイダ・サイトにアクセスします。いずれの場合も、WebユーザーはIDプロバイダによって認証され、IDプロバイダはそのユーザーのかわりにユーザーID情報を含むアサーションを生成します。IDプロバイダはそのアサーションをサービス・プロバイダに送信し、サービス・プロバイダはそのアサーションからID情報を抽出して、ローカル・セキュリティ・レルムのサブジェクトにマッピングします。

- Webサービス・セキュリティ(WS-Security) SAML Token Profile 1.1
SAMLトークン・プロファイルはWS-Security標準のコア・セットの一部であり、SAMLアサーションをWebサービス・セキュリティに使用する方法が規定されています。WebLogic Serverでは、SAML 2.0およびSAML 1.1アサーションのサポートを含めて、SAML Token Profile 1.1をサポートしています。SAML Token Profile 1.1はSAML Token Profile 1.0と後方互換性があります。

次の節では、WebLogic ServerでのSAMLのサポートについて説明します。

- SAMLフレームワークの概念

- WebLogic Serverで提供されるSAMLコンポーネント

SAMLフレームワークの概念

SAMLフレームワークは、以下の概念に基づいています。

注意:
これらの概念の用語は、特に、この節で説明しているようにWebLogic Server管理コンソールで表示される対応するエンティティについては、SAML 1.1とSAML 2.0で多少異なります。

- IDプロバイダ - ユーザーが認証済みで、関連する属性が付与されていることをアサートするシステム(管理ドメイン)。例: Dan Murphyというユーザーがいて、dmurphy@company.comという電子メール・アドレスを持っており、パスワード・メカニズムによってこのドメインに認証されました。IDプロバイダは、SAML認証局、アサーティング・パーティ、またはソース・サイトとも呼ばれ、しばしばIdPと略されます。
WebLogic ServerインスタンスをIDプロバイダのロールで機能するように構成できます。IDプロバイダは発行者URI (名)によって認識されます。WebLogic Serverでは、SAML資格証明マッピング・プロバイダがこの機能を提供します。(構成する特定の資格証明マッピング・プロバイダは、使用するSAMLのバージョンに固有です。)

注意:
WebLogic ServerインスタンスでSAML 1.1サービスを構成する場合、WebLogic Server管理コンソールでは、IDプロバイダのかわりにソース・サイトという用語を使用しています。

- サービス・プロバイダ - IDプロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム(管理ドメイン)。SAMLには、提供されたアサーションをサービス・プロバイダが信頼できるようにするための複数のメカニズムが定義されています。サービス・プロバイダは、リライイング・パーティまたは宛先サイトとも呼ばれ、しばしばSPと略されます。
サービス・プロバイダが提供されたアサーションを信頼したとしても、そのサブジェクトがローカル・リソースにアクセスできるかどうかはローカル・アクセス・ポリシーで定義されます。したがって、ユーザーがDan Murphyであることをサービス・プロバイダが信頼しても、Dan Murphyがドメイン内のすべてのリソースにアクセスできるとは限りません。

WebLogic Serverインスタンスをサービス・プロバイダのロールで機能するように構成できます。その場合、IDプロバイダ・パートナとの信頼関係を確立する必要があります。WebLogic Serverでは、SAML IDアサーション・プロバイダがこの機能を提供します。(構成する特定のIDアサーション・プロバイダは、使用するSAMLのバージョンに固有です。)

WebLogic ServerインスタンスでSAML 1.1サービスを構成する場合、WebLogic Server管理コンソールでは、サービス・プロバイダのかわりに宛先サイトという用語を使用しています。

- アサーションは、IDプロバイダによって作成された1つまたは複数の文を提供する情報のパッケージです。以下の種類の文がサポートされます。

- サブジェクトが認証された時間と方法を示す認証文

- サブジェクト固有の情報(サブジェクトが属すグループなど)を提供する属性文

- サブジェクトに何を許可するかを示す認可文

注意:
WebLogic ServerでのSAMLアサーションについては、次の点に注意してください。

- 属性文は、グループ情報を含めることのみを目的としてサポートされます。SAML認証プロバイダは、SAMLアサーションからグループ情報を取得できます(『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSAML認証プロバイダの構成に関する項を参照してください。)

- SAML認可は、このリリースのWebLogic Serverではサポートされません。

- プロトコル - SAMLでは、アサーションを取得するためのリクエスト/レスポンス・プロトコルが定義されています。SAMLリクエストでは、特定の既知のアサーションを要求するか、認証または属性を決定するための問合せを実行できます。SAMLレスポンスではリクエストされたアサーションが返されます。プロトコル・メッセージのXML形式と使用可能な拡張は、XMLスキーマで定義されています。
WebLogic Serverでは、認証リクエスト・プロトコルがサポートされています。このプロトコルでは、認証応答(つまり、<Response>文を含むメッセージ)を返信させる認証リクエスト(つまり、<AuthnRequest>文を含むメッセージ)が定義されます。認証レスポンスには、プリンシパルに関連するアサーションが含まれます。

通常、認証リクエストはサービス・プロバイダからIDプロバイダに送信され、その結果、認証レスポンスが返されます。認証リクエスト・プロトコルは、WebブラウザのSSOプロファイル・サポートに使用されます。

- バインディング - バインディングには、SAMLプロトコルがトランスポート可能な低レベルの通信プロトコルまたはメッセージング・プロトコル(HTTPやSOAPなど)が定義されています。バインディングは、SAMLプロトコルがトランスポート・プロトコルおよびメッセージング・プロトコルにどのようにマップしているかを詳細に示します。たとえば、SAML <AuthnRequest>メッセージのHTTPへのマッピングなどを示します。
SAML 1.1の場合、WebLogic ServerではHTTP POSTおよびHTTPアーティファクトがプロファイルとしてサポートされます。SAML 2.0の場合、Web SSOプロファイルのHTTP POSTおよびHTTPアーティファクト・バインディングがサポートされます。

SAML 2.0の場合、WebLogic Serverでは、Web SSOプロファイルのHTTPリダイレクト・バインディングが追加されます。

- プロファイル - アサーションおよびプロトコル・メッセージの特定のフローの技術的な記述です。SAMLを特定の目的に使用する方法を定義します。プロファイルは、WebLogic ServerでサポートされるWeb SSOプロファイルやSAMLトークン・プロファイルなど、特定の使用例をサポートするために使用されるプロトコル、バインディング、アサーション構造の組み合わせです。

- メタデータ・ファイル - SAML 2.0では、パートナ間で構成情報を交換するために新しいメタデータ・スキーマが定義されています。WebLogic Serverでは、このスキーマは、ローカル・サイトの構成データを作成して、それをファイルに公開し、Web SSOプロファイルとともに使用してパートナと共有する機能によってサポートされます。パートナは、このメタデータ・ファイルをインポートしてこの構成データを取得し、パートナのレジストリへの設定と、SAMLメッセージをより高い一貫性および信頼性で転送および消費できるようにするために使用します。メタデータ・ファイルはWS-Security SAML Token Profile 1.1では使用されません。

これらの概念の詳細とSAMLアーキテクチャへのこれらの概念の適用については、次のトピックを参照してください。

- SAML V1.1の場合、『Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1』(http://www.oasis-open.org/committees/download.php/6628/sstc-saml-tech-overview-1.1-draft-05.pdf)を参照してください。

- SAML V2.0の場合、『Security Assertion Markup Language (SAML) 2.0 Technical Overview』(http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf)を参照してください。

WebLogic Serverで提供されるSAMLコンポーネント

SAML 1.1および2.0のサポートは、次のWebLogic Serverコンポーネントで提供されます。

- SAMLセキュリティ・プロバイダ

- シングル・サインオン・サービス

- WebサービスでのSAML Token Profile 1.1のサポート

SAMLセキュリティ・プロバイダ

WebLogic Serverでは、SAML 1.1および2.0をサポートするために次のセキュリティ・プロバイダが付属しています。

表3-1 SAMLをサポートするためにWebLogic Serverに付属しているセキュリティ・プロバイダ

サポート対象

プロバイダ

説明

SAML 1.1

SAML資格証明マッピング・プロバイダ・バージョン2

SAML 1.1アサーションを生成します。このプロバイダは、IDプロバイダ(WebLogic Server管理コンソールでは「ソース・サイト」)として機能するWebLogic Serverインスタンスのために構成する必要があります。

SAML 1.1

SAML資格証明マッピング・プロバイダ・バージョン1

SAML 1.1アサーションを生成します(非推奨)。

SAML 1.1

SAML IDアサーション・プロバイダ・バージョン2

SAML 1.1アサーションを消費します。このプロバイダは、サービス・プロバイダ(WebLogic Server管理コンソールでは「宛先サイト」)として機能するWebLogic Serverインスタンスのために構成する必要があります。

SAML 1.1

SAML IDアサーション・プロバイダ・バージョン1

SAML 1.1アサーションを消費します(非推奨)。

SAML 2.0

SAML 2.0資格証明マッピング・プロバイダ

SAML 2.0アサーションを生成します。このプロバイダは、IDプロバイダとして機能するWebLogic Serverインスタンスのために構成する必要があります。

SAML 2.0

SAML 2.0 IDアサーション・プロバイダ

SAML 2.0アサーションを消費します。このプロバイダは、サービス・プロバイダとして機能するWebLogic Serverインスタンスのために構成する必要があります。

SAML 1.1および2.0

SAML認証プロバイダ

SAML 1.1およびSAML 2.0のIDアサーション・プロバイダの「仮想ユーザー」機能を有効にする(『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSAML認証プロバイダの構成に関する項を参照してください。)

シングル・サインオン・サービス

WebLogic Serverは、SAML IDプロバイダ(IdP)またはサービス・プロバイダ(またはその両方)として機能するように構成できます。IdPとして機能させる場合、IdPがアサーションを生成できるようにSAML資格証明マッピング・プロバイダを構成する必要があります。サービス・プロバイダとして機能させる場合、サービス・プロバイダがアサーションを消費できるようにSAML IDアサーション・プロバイダを構成する必要があります。

SAMLシングル・サインオン・サービス(SSO)はサーバー単位で構成します。クラスタなど、ドメイン内の複数のサーバーでSAML SSOを有効にするには、次の方法をお薦めします。

1. RDBMSセキュリティ・ストアが構成されているドメインを作成します。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。

2. SSOサービスが、各サーバー・インスタンスでまったく同じように構成されていることを確認します。

WebサービスでのSAML Token Profile 1.1のサポート

WebLogic Server Webサービスでは、SAML Token Profile 1.1がサポートされています。この機能は、SAML 2.0およびSAML 1.1アサーションをサポートし、SAML Token Profile 1.0と後方互換性があります。

SAMLトークンは、WS-SecurityPolicyアサーションを適切に使用することでWebサービスで構成されます。

注意:
SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。以前の「WLS 9.2セキュリティ・ポリシー」では、SAML Token Profile 1.0/SAML 1.1のみがサポートされます。

SAMLトークン・プロファイルを使用する場合、使用するSAMLバージョンとアサーションの使い方に基づいて、適切なSAMLセキュリティ・プロバイダ(SAML 2.0/SAML 1.1の資格証明マッピング・プロバイダまたはIDアサーション・プロバイダのいずれか)を構成する必要があります。

シングル・サインオン(SSO)

シングル・サインオンは、ユーザーが一度アプリケーション・コンポーネントにサインオンすれば、他の様々なアプリケーション・コンポーネントに(それらが独自の認証方式を使用している場合でも)アクセスできる機能です。シングル・サインオンを使用すると、ユーザーはすべてのアプリケーション、Webサイト、メインフレーム・セッションに、1つのIDでセキュアにログインできます。WebLogic Serverでは、以下の環境でのシングル・サインオン(SSO)が可能です。

- SAMLの使用によるWebブラウザとHTTPクライアント

- デスクトップ・クライアント

SAMLの使用によるWebブラウザとHTTPクライアント

Security Assertion Markup Language (SAML)を使用すると、WebLogic Serverドメインで実行されているWebアプリケーションまたはWebサービスと、Webブラウザまたはその他のHTTPクライアントの間でクロス・プラットフォーム認証を実行できます。WebLogic ServerではSAMLに基づくシングル・サインオン(SSO)がサポートされています。シングル・サインオン(SSO)構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証されるので、別個にログインする必要がありません。

注意:
WebLogic Server管理コンソールを使用してSAMLを構成する場合、いくつかのSAMLエントリの名前がSAML 1.1と2.0では異なります。この節では、主な用語の違いについて説明しています。

以下の手順は、SAML SSOの動作を示す一般的なシナリオを示しています。

1. Webユーザーが、SAMLアサーションを介して認証を受け付けるよう構成されているサイトのターゲット・リソースにアクセスしようとします。
WebLogic Server管理コンソールでSAML 1.1を構成する場合、このサイトは宛先サイトと呼ばれます。SAML 2.0では、このサイトはサービス・プロバイダと呼ばれます。

2. サービス・プロバイダは、ユーザーの資格証明を、そのユーザーのSAMLアサーションを生成できる中央サイトで認証する必要があるかどうかを判別します。サービス・プロバイダは、認証リクエストをその中央サイトにリダイレクトします。
SAML 1.1では、SAMLアサーションを生成するサイトはソース・サイトと呼ばれます。SAML 2.0では、このサイトはIDプロバイダと呼ばれます。SAMLのバージョンに関係なくこのサイトはSAML認証局と呼ぶ場合もあります。

3. ユーザーがIDプロバイダにログインします。ログインは通常、そのサイトによってホストされるログインWebアプリケーションを介して行います。IDプロバイダはユーザーを認証し、SAMLアサーションを生成します。

4. IDプロバイダによって提供され、ユーザーとターゲット・リソースに関連付けられたSAMLアサーションの情報が、プロトコル交換によってIDプロバイダからサービス・プロバイダ・サイトに転送されます。
一連のHTTP交換を経て、ユーザーのブラウザがサービス・プロバイダのアサーション・コンシューマ・サービス(ACS)に転送されます。WebLogic ServerのSAML IDアサーション・プロバイダがACSの一部を構築します。

5. IDアサーション・プロバイダは、アサーションに含まれているIDをローカル・セキュリティ・レルムのサブジェクトにマッピングします。リクエストされた対象のアクセス・ポリシーを評価し、その対象に対してユーザーを認可するかどうかを判断します。アクセスが認可されると、IDプロバイダ・サイトによって認証されたユーザーが、サービス・プロバイダ・サイトによって認証されたユーザーとして受け付けられます。これによって、WebベースのSSOが実現されます。

OASIS SAML標準の基本情報については、次のトピックを参照してください。

- SAML V1.1については、『Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1』(http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf)を参照してください。

- SAML V2.0については、次のトピックを参照してください。

- 『Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0』(http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf)

- 『Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0』(http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf)

WebブラウザとHTTPクライアントでのSSOをWebLogic Serverに実装する方法については、「WebLogicセキュリティ・フレームワークによるシングル・サインオン」を参照してください。

デスクトップ・クライアント

デスクトップ・クライアントでのSSOには、Windows Active Directory環境で認証済みのMicrosoftクライアントと、HTTPベースの認証を使用します。Windows Active Directory環境では、セキュリティ・プロトコルとしてKerberosを使用します。Kerberosは、異種のレルムのネットワーク認証を提供します。つまり、Windowsドメインにログインしたユーザーは、アプリケーション・サーバーで実行されているWebアプリケーションにアクセスでき、Windows Active Directoryの資格証明を使用してサーバーに認証されます。アプリケーション・サーバーは、Kerberosをサポートするすべてのプラットフォームで実行できます。

Webサーバーは、ブラウザからのリクエストを受信すると、Kerberosプロトコルを使用して認証するようブラウザにリクエストできます。このプロトコルでは、HTTPで認証が実行され、ブラウザ(ほとんどの場合Internet Explorer)から委託資格証明を渡されたWebアプリケーションが、ユーザーにかわってそれ以降のKerberosベースのサービスにログインします。

HTTPサーバーがMicrosoftクライアントをログインさせるときには、WWW-Authorization:Negotiateヘッダーを含む401 UnauthorizedレスポンスがHTTPリクエストに返されます。次に、ブラウザがキー配布センター(KDC)/チケット認可サービス(TGS)にコンタクトしてサービス・チケットを入手します。その際には、チケット・リクエスト用の特別なサービス・プリンシパル名が選択されます。返されたチケットはSPNEGOトークンにラップされており、これをエンコードしたものがHTTPリクエストによってサーバーに返信されます。このトークンのラップを解き、チケットを認証します。認証が完了すると、リクエストされたURLに対応するページが返されます。

MicrosoftクライアントでのSSOがWebLogic Serverでどのように実装されているかの詳細は、「デスクトップSSOのプロセス」を参照してください。

認可

認可とは、ユーザーのIDなどの情報に基づいて、ユーザーとWebLogicリソースとの対話を管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Serverでは、認可プロバイダはユーザーとWebLogicリソースとの対話を制限して、整合性、機密性、および可用性を確保します。

以下の節では、認可の概念と機能について説明します。

- WebLogicリソース

- セキュリティ・ポリシー

- ContextHandler

- アクセス決定

- 裁決

- JACC (Java Authorization Contract for Containers)

WebLogicリソース

WebLogicリソースは、基底のWebLogic Serverエンティティを表す構造化オブジェクトです。セキュリティ・ロールとセキュリティ・ポリシーを使用すると、これらのオブジェクトを権限のないアクセスから保護できます。

WebLogicリソースは階層化されています。このため、セキュリティ・ロールとセキュリティ・ポリシーは自由なレベルで定義できます。たとえば、エンタープライズ・アプリケーション(EAR)全体、複数のEJBを含むEnterprise JavaBean (EJB) JAR、そのJAR内の特定のEnterprise JavaBean (EJB)、そのEJB内の単一のメソッドなどに対してセキュリティ・ロールとセキュリティ・ポリシーを定義できます。

以下のWebLogicリソースの実装を使用できます。

- 管理リソース

- アプリケーション・リソース

- コンポーネント・オブジェクト・モデル(COM)リソース

- エンタープライズ情報システム(EIS)リソース

- Enterprise JavaBean (EJB)リソース

- Java Database Connectivity (JDBC)リソース

- Java Message Service (JMS)リソース

- Java Naming and Directory Interface (JNDI)リソース

- サーバー・リソース

- Webアプリケーション・リソース

- Webサービス・リソース

- ワーク・コンテキスト・リソース

注意:
これらのWebLogicリソースの各実装の詳細は、Oracle WebLogic Server Java APIリファレンスを参照してください。

セキュリティ・ポリシー

セキュリティ・ポリシーはアクセス制御リスト(ACL)にかわるもので、「誰がWebLogicリソースにアクセスできるか」という問いに答えるものです。セキュリティ・ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間に関連付けを定義するときに作成されます。また、セキュリティ・ポリシーに日時制約を定義することもできます。WebLogicリソースは、セキュリティ・ポリシーが割り当てられるまでは保護されません。

セキュリティ・ポリシーは、定義済みの任意のWebLogicリソース(EJBリソースやJNDIリソースなど)、またはWebLogicリソースの特定のインスタンス(Webアプリケーション内のEJBメソッドやサーブレット)の属性または操作に割り当てることができます。セキュリティ・ポリシーをWebLogicリソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ・ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ・ポリシーは、WebLogicリソースのタイプに割り当てられたセキュリティ・ポリシーをオーバーライドします。定義済みのWebLogicリソースのリストについては、「WebLogicリソース」を参照してください。

セキュリティ・ポリシーは、認可プロバイダのデータベースに格納されます。デフォルトでは、XACML認可プロバイダがドメイン内に構成され、セキュリティ・ポリシーは組込みLDAPサーバーに格納されます。

ユーザーまたはグループを使用してセキュリティ・ポリシーを作成する場合は、そのユーザーまたはグループがセキュリティ・レルムで構成された認証プロバイダのセキュリティ・プロバイダ・データベースで定義されている必要があります。セキュリティ・ロールを使用してセキュリティ・ポリシーを作成する場合は、そのセキュリティ・ロールがセキュリティ・レルムで構成されたロール・マッピング・プロバイダのセキュリティ・プロバイダ・データベースで定義されている必要があります。XACML認証プロバイダおよびロール・マッピング・プロバイダは、デフォルトでは組込みLDAPサーバー内のデータベースに構成されています。

デフォルトで、WebLogic ServerにはWebLogicリソース用のセキュリティ・ポリシーが定義されています。これらのセキュリティ・ポリシーは、セキュリティ・ロールとデフォルト・グローバル・グループに基づいています。また、必要に応じてセキュリティ・ポリシーはユーザーに基づくこともできます。ただし、セキュリティ・ポリシーは、ユーザーまたはグループではなく、セキュリティ・ロールに基づいて作成することをお薦めします。セキュリティ・ロールに基づいてセキュリティ・ポリシーを作成すると、ユーザーまたはグループに付与されるセキュリティ・ロールに基づいてアクセスを管理できます。管理の方法としてはこちらの方が効率的です。WebLogicリソースのデフォルト・セキュリティ・ポリシーのリストについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のデフォルトのルート・レベルのセキュリティ・ポリシーに関する項を参照してください。

ContextHandler

ContextHandlerは、リソース・コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール・マッピング決定を行うセキュリティ・プロバイダに渡す高性能なWebLogicクラスです。ContextHandlerインタフェースを使用すると、内部WebLogicリソース・コンテナでWebLogicセキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandlerは本質的には名前と値のリストなので、セキュリティ・プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandlerの使用には、WebLogicリソース・コンテナとセキュリティ・プロバイダの間の緊密な連携が不可欠です。ContextHandlerの名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElementオブジェクトによって表されます。

現在、3種類のWebLogicリソース・コンテナ(サーブレット・コンテナ、EJBコンテナ、Webサービス・コンテナ)がContextHandlerをWebLogicセキュリティ・フレームワークに渡します。これらのコンテキスト要素の値は、裁決プロバイダ、IDアサーション・プロバイダ、認可プロバイダ、資格証明マッピング・プロバイダ、およびロール・マッピング・プロバイダで調べるか、認証プロバイダで使用するLoginModuleで調べることができます。監査イベントをポストするためにセキュリティ・プロバイダが実装される場合に使用するAuditContextインタフェースの実装によっても、コンテキスト要素の値を調べることができます。

特定のコンテキスト要素の値に関する詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のContextHandlerとWebLogicリソースに関する項を参照してください。

アクセス決定

認証プロバイダのLoginModuleと同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作をWebLogicリソースに対して実行する許可をサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答をPERMIT、DENY、またはABSTAINのいずれかで返します。

裁決

裁決では、セキュリティ・レルムで複数の認可プロバイダが構成されている場合に発生するおそれのある認可上の競合を、それぞれの認可プロバイダのアクセス決定の結果を比較検討することによって解消します。WebLogic Serverでは、裁決プロバイダを使用して、複数のアクセス決定から返される結果を調停し、PERMITかDENYの最終判定を下します。また、裁決プロバイダでは、単一の認可プロバイダのアクセス決定からABSTAINの回答が返されたときにどうすべきかを指定することもできます。

IDと信頼

秘密鍵、デジタル証明書、および信頼性のある認証局によって、WebLogic Server環境でIDと信頼が確立および検証されます。

公開鍵は、デジタル証明書に組み込まれています。秘密鍵とデジタル証明書によってIDが提供されます。信頼性のある認証局(CA)証明書によって、証明書の「信頼」が確立されます。証明書と証明書チェーンは、信頼関係が確立される前に検証する必要があります。

ここでは、IDと信頼に関係する概念について解説します。詳細については、以下を参照してください。

- 秘密鍵

- デジタル証明書

- 認証局

- 証明書の検索と検証

秘密鍵

WebLogic Serverでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバー用に公開鍵と秘密鍵が生成されます。これらのキーは関連付けられているので、公開鍵で暗号化されたデータは、対応する秘密鍵を使用することによってのみ復号化できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。

デジタル証明書

デジタル証明書とは、インターネットなどのネットワークを経由して、プリンシパルおよびエンティティの一意のIDを確認するための電子的なドキュメントのことです。デジタル証明書は、認証局として知られる信頼性のある第三者によって確認されたユーザーまたはエンティティのIDを、特定の公開鍵に安全にバインドします。公開鍵と秘密鍵(秘密鍵)を組み合せることで、デジタル証明書のオーナーに一意のIDが提供されます。

デジタル証明書を使用すると、特定の公開鍵が実際に特定のユーザーまたはエンティティに属しているかどうかを確認できます。デジタル証明書の受信側は、証明書内の公開鍵を使用して、デジタル署名が対応する秘密鍵で作成されたものかどうかを確認します。こうした確認が終わると、この推論のチェーンによって、対応する秘密鍵のオーナーがデジタル証明書に名前のあるサブジェクトであること、そしてそのデジタル署名を作成したのがそのサブジェクトであることを確認できます。

一般に、デジタル証明書には以下のように様々な情報が入っています。

- サブジェクト(保持者、オーナー)の名前と、デジタル証明書を使用するWebサーバーのURLや個人の電子メール・アドレスなど、そのサブジェクトの一意のIDを確認するために必要なその他の情報

- サブジェクトの公開鍵

- デジタル証明書を発行した認証局の名前

- シリアル番号

- (開始日と終了日で定義される)デジタル証明書が有効性を持つ期間(存続期間)

最も広く使われているデジタル証明書のフォーマットは、ITU-T X.509国際標準で定義されているものです。X.509標準に準拠していればどのアプリケーションを使っても、デジタル証明書を読み書きできます。WebLogic Serverの公開鍵インフラストラクチャ(PKI)では、X.509バージョン3 (X.509v3)に準拠したデジタル証明書が認識されます。VerisignやEntrustなどの認証局から証明書を取得することをお薦めします。

詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSSLの構成に関する項を参照してください。

認証局

デジタル証明書は、認証局(CA)によって発行されます。デジタル証明書と公開鍵の発行対象に対してIDを保証できる、信頼性のある第三者機関または企業は、CAとなることができます。CAは、デジタル証明書を作成する際に、証明書が改ざんされればわかるように秘密鍵を使って署名します。CAは、署名したデジタル証明書を要求側に返します。

要求側は、CAの公開鍵を使って発行CAの署名を確認します。CAの公開鍵は、低レベル認証局の公開鍵の妥当性を保証する高レベル認証局から発行された証明書を提供することで利用できるようになります。この方式によって、認証局の階層が構築されます。この階層は、最終的に、ルート証明書と呼ばれる、最上位の自己署名証明書で終わります。これは、証明にそれ以外の一切の公開鍵が不要であるためです。

ルート証明書は、信頼性のある(ルート)CAによって発行されます。高レベルのCAによって署名されたCA証明書は中間証明書として知られています。中間証明書の発行元は中間CAとして知られています。

受信側がすでに信頼性を確認済みの、該当CAよりも高レベルのCAが署名した中間CAの公開鍵が入ったデジタル証明書を持っている場合、暗号化されたメッセージの受信側は、中間CAの公開鍵を再帰的に信頼します。この点では、デジタル証明書はデジタルの信頼関係の踏み台です。つまり、最終的には、いくつかの上位CAの公開鍵の信頼性を確認するだけで済みます。証明書のチェーン(証明書パス)を通じて、多数のユーザーのデジタル署名の信頼を確立できます。

証明書パスに含まれる証明書の数は、証明書パスの長さと呼ばれます。X.509規格には、ルート証明書に指定できる制約pathLenConstraintが含まれています。ルート証明書を作成する際、CAはこの制約を指定して、証明書パス内でそのルート証明書までたどる中間証明書の最大数を制限できます。実際、この制約によって証明書パスの長さが制限され、これはSSLシェイクハンド時に確認される信頼のプロパティになります。

つまり、通信中のエンティティのIDは、このようにしてデジタル署名によって確立できますが、デジタル署名による信頼は、信頼性を確認するための公開鍵の範囲にとどまります。

詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSSLの構成に関する項を参照してください。

証明書の検索と検証

セキュリティを公開鍵技術に依存するアプリケーションでは、ユーザーの公開鍵が真正であることが保証されなければなりません。ユーザーが、最初の証明書を発行した信頼性のあるCAを再帰的に指す証明書のチェーン(これを目的の証明書と呼ぶ)を持っている場合があります。信頼を確立するために証明書チェーンを使用するには、まず検証する必要があります。また、ユーザーが信頼性のあるCAから目的の証明書への完全なチェーンを持っていない場合もあります。目的の証明書から信頼性のあるCAへの有効な証明書チェーンを完了させることは、公開鍵技術のもう1つの要件です。

WebLogic Serverでは、証明書の検証は証明書検索および検証(CLV)フレームワークによって実行されます。このフレームワークは、着信双方向SSL、発信SSL、アプリケーション・コード、およびWebLogic Webサービスについて、X.509証明書チェーンを完了および検証します。CLVフレームワークは、証明書または証明書チェーンを受け取り、チェーンを完了させ(必要な場合)、証明書チェーン内の証明書を検索および検証します。フレームワークでは、目的の証明書、サブジェクトDN、発行者DNとシリアル番号、サブジェクト・キー識別子、およびX.509による指紋を使用して証明書チェーンを検索および検証します。加えて、証明書チェーンに対する追加の検証(失効チェックなど)を実行することもできます。

CLVフレームワークは、JDKアーキテクチャと、証明書チェーンを検索および検証するためのプラグイン・フレームワークに基づいています。CLVプロバイダは、JDK証明書パス・ビルダーと証明書パス検証プロバイダAPI/SPIを使用して作成されています。

Secure Sockets Layer (SSL)

WebLogic Serverは、Webを介して接続されたアプリケーション間のセキュリティが保護された通信を可能にするSSL通信を完全サポートしています。今回のWebLogic Serverのリリースには、次の使用に対するSSLスタックとしてJava Secure Socket Extension (JSSE)を使用するためのサポートが含まれます。

- 受信時SSL接続

- WebLogic SSLのAPIを使用する送信時SSL接続(アプリケーションは常に送信SSL接続に対してJSSEを直接呼び出すことが可能でした)。

注意:
WebLogic Serverバージョン12.1.1以降では、サポートされるSSL実装はJSSEのみになります。CerticomベースのSSL実装はなくなり、WebLogic Serverでサポートされなくなりました。
JSSEの詳細情報は、次の場所にある『Java Secure Socket Extension (JSSE)リファレンス・ガイド』を参照してください。

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-features.html

この節では、以下の内容について説明します。

- SSLの機能

- 暗号スイート

- SSLトンネリング

- 一方向および双方向SSL認証

- SSLの構成

- ホスト名検証

- トラスト・マネージャ

- FIPSサポート

SSLの機能

WebLogic Serverでは、SSLのpure-Java実装が提供されます。一般的に、SSLは以下の機能を提供します。

- 通信を行うアプリケーションが互いの身元を認証するために利用するメカニズム

- アプリケーション間でやり取りするデータの暗号化

SSL使用時には、ターゲット(サーバー)がイニシエータ(クライアント)に対して常にターゲット自体を認証します。任意で、ターゲットがリクエストする場合、イニシエータはイニシエータ自体をターゲットに対して認証できます。暗号化によって送信されるデータにスクランブルがかけられます。SSL接続はデジタル証明書をやり取りするアプリケーション間のハンドシェークで始まり、使用する暗号化アルゴリズムの取決め、そのセッションの残りで使用する暗号鍵の生成と続きます。

具体的には、SSLが提供するセキュリティ機能は以下のとおりです。

- サーバー認証 - WebLogic Serverは、信頼性のある認証局が発行したデジタル証明書を使用して、クライアントに対して認証します。SSLでは最低でも、サーバーが自身のデジタル証明書を使用してクライアントに対して認証を行うことが必要になります。デジタル証明書の提示がクライアントに要求されない場合の接続タイプは、いわゆる一方向SSL認証です。

- クライアントIDの検証 - 場合によっては、WebLogic Serverに対するデジタル証明書の提示がクライアントに要求されることもあります。WebLogic Serverで、そのデジタル証明書が信頼性のある認証局によって発行されたものであることが確認されると、SSL接続が確立されます。デジタル証明書が提示されなかったり、確認されなかったりした場合、SSL接続は確立されません。この接続タイプは、相互認証の一形態である、いわゆる双方向のSSL認証です。

- 機密性 - クライアントのリクエストとサーバーのレスポンスは暗号化され、ネットワーク経由でやり取りされるデータの機密性が保持されます。

- データの整合性 - 各SSLメッセージには、元のデータから計算されたメッセージ・ダイジェストが含まれます。受け手側では、解読されたデータから新しいダイジェストを計算し、メッセージとともに受信したダイジェストと比較します。データが変更されているとダイジェストが一致せず、改ざんが検出されます。

Webブラウザを使ってWebLogic Serverと通信する場合は、Hyper-Text Transfer Protocol with SSL (HTTPS)を利用して、ネットワーク通信の安全性を確保できます。

暗号スイート

暗号スイートとは、認証、鍵の同意、暗号化、および整合性保護で使用されるセキュリティ・アルゴリズムおよび鍵サイズを定義する暗号化パラメータの組合せです。

暗号スイートは、通信の整合性を保護します。たとえば、RSA_WITH_RC4_128_MD5という暗号スイートは、鍵交換用のRSA、一括暗号化用の128ビット鍵を持つRC4、およびメッセージ・ダイジェスト用のMD5を使用します。

JDKデフォルトJSSEプロバイダによってサポートされる暗号スイートの設定であるSunJSSEは、次の場所にある『Java(tm) Secure Socket Extension (JSSE)リファレンス・ガイド』で参照できます。

http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

JSSEベースのSSL実装を使用するためのWebLogic Serverの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のJSSEベースのSSL実装の使用に関する項を参照してください。

SSLトンネリング

WebLogic Serverでは、HTTP、T3、およびIIOPプロトコルをSSLでトンネリングします。SSLは、以下のようにWebブラウザおよびJavaクライアントで使用できます。

- Webブラウザが、サーバーへのSSL接続をHTTPSで確立します。ブラウザは、このSSL接続を介して、HTTPリクエストを送信してHTTPレスポンスを受信します。例:
https://myserver.com/mypage.html

WebLogic ServerではSSLのバージョニングがサポートされます。つまり、このプロトコルでWebブラウザを含むあらゆるクライアントと通信できます。

- HTTP/T3プロトコルを使用するJavaクライアントをSSLでトンネリングします。例:
t3s://myserver.com:7002/mypage.html

WebLogic Server内で動作するJavaクライアントは、他のWebLogic ServerにT3S接続するか、またはWebサーバーやセキュアなプロキシ・サーバーなどSSLをサポートする他のサーバーにHTTPS接続します。

一方向および双方向SSL認証

WebLogic Serverでは、一方向と双方向のSSL認証がサポートされています。一方向SSL認証では、ターゲット(サーバー)が発信元(クライアント)に対してデジタル証明書を提示して身元を証明する必要があります。クライアントは、2つのチェックを行って、デジタル証明書を検証します。

1. 証明書が信頼できるか(つまり、クライアントの信頼性のあるCAによって発行されたか)、有効か(期限切れでないか)、その他の証明書制約を満たすかをクライアントが検証します。

2. 証明書のサブジェクトの共通名(CN)フィールドの値が、クライアントが接続しようとしているサーバーのホスト名と一致するかどうかをクライアントがチェックします。

上記のチェックの両方でtrueが返されると、SSL接続が確立します。

双方向のSSL認証では、クライアントとサーバーの両方がデジタル証明書を提示しないと、両者の間でSSL接続が有効になりません。そのため、この場合、WebLogic Serverはクライアントに対して自身を認証するだけでなく(証明書認証の最低限の要件)、リクエスト側のクライアントにも認証を要求します。双方向SSL認証は、アクセスを許可する対象を信頼性のあるクライアントに制限する場合に便利です。

図3-3に、WebLogic ServerのSSL接続と、一方向SSL、双方向SSL、またはその両方をサポートする接続を示します。Webブラウザ・クライアント、Webサーバー、ファット・クライアント、Webサービス・クライアント、およびSSLサーバーの接続に対して一方向SSLまたは双方向SSLのいずれかを構成できます。WebLogic Serverは、SSL接続が一方向または双方向のどちらに構成されているかを判別します。SSLはWebLogic Server管理コンソールを使用して構成します。

図3-3 WebLogic ServerがSSL接続をサポートする仕組み

SSLの構成

デフォルトでは、WebLogic Serverは一方向のSSL認証用に構成されますが、SSLポートは無効化されています。WebLogic Server管理コンソールを使用すると、双方向のSSL認証用にWebLogic Serverを構成できます。

- クライアントからサーバーへの一方向SSLを使用するには、サーバーのSSLポートを有効にし、サーバーのIDとクライアントの信頼を構成します。

- クライアントとサーバーの間の双方向SSLを使用するには、サーバーの双方向SSLを有効にし、サーバーの信頼とサーバーのIDを構成します。
どちらの場合も、ピアのID証明書を発行した信頼性のあるCA証明書が、信頼性のあるCA証明書に含まれている必要があります。この証明書は、ルートCA証明書でなくても構いません。

サーバーのデジタル証明書を取得するには、公開鍵、秘密鍵、および公開鍵を含む証明書署名リクエスト(CSR)を生成します。認証局にCSRリクエストを提出し、署名されたデジタル証明書を取得する手順に従います。

秘密鍵、デジタル証明書、および必要に応じて信頼性のあるCA証明書を取得したら、WebLogic ServerがID検証にそれらを使用できるよう、それらを格納する必要があります。秘密鍵と証明書は、キーストアに格納します。

ブラウザを使用してWebLogic Serverアプリケーションと接続する場合にSSLを使用するには、単純にHTTPSとセキュア・ポート(ポート番号7002)をURLで指定します。例: https://localhost:7002/examplesWebApp/SnoopServlet.jsp (ここで、localhostはWebアプリケーションをホストしているシステムの名前)のように指定します。

ホスト名検証

ホスト名検証は、SSL接続先のホスト名が予定していた通信先、または許可された通信先であることを確認するプロセスです。Webクライアント(Webブラウザ、WebLogicクライアント、またはクライアントとして機能しているWebLogic Server)が別のアプリケーション・サーバーとのSSL接続をリクエストする場合に、中間者攻撃を防ぎます。

SSLクライアントのSSLハンドシェーク機能としてのデフォルトの動作は、SSLサーバーのデジタル証明書のSubjectDNにある共通名と、SSL接続の開始に使用するSSLサーバーのホスト名を比較することです。これらの名前が一致しない場合はSSL接続が中断されます。

トラスト・マネージャ

トラスト・マネージャは、デフォルトのSSL信頼検証ルールをオーバーライドする方法を提供します。トラスト・マネージャにより、サーバーにアクセスしてきたクライアントを信頼するかどうかをサーバーが決定できます。トラスト・マネージャを使用すると、SSL接続を続行する前にカスタム検証を実行できます。たとえば、トラスト・マネージャを使用して、特定の地域(町、州、国など)のユーザーやその他の特殊な属性を持つユーザーだけがSSL接続を介してアクセスを取得できるように指定することができます。

WebLogic Serverは、カスタム・トラスト・マネージャ実装がSSLハンドシェイク中に呼び出されるようにするインタフェースを提供します。カスタム実装は、SSL実装の妥当性チェックによって検出されたハンドシェイク・エラーをオーバーライドし、独自の証明書ルールに基づいてエラーを提起して、送信SSLが証明書の参照と検証を使用するかどうかを制御できます。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のトラスト・マネージャの使用に関する項およびCertPathトラスト・マネージャの使用に関する項を参照してください。

FIPSサポート

Federal Information Processing Standards (FIPS) 140-2は、アメリカ合衆国政府の機密でも未分類の使用に関する要件を記載した規格です。WebLogic Serverは、FIPS互換(FIPS 140-2)機密モジュールを使用する機能をサポートします。

詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のFIPSモードの有効化に関する項を参照してください。

ファイアウォール

ファイアウォールとは、2つのネットワーク間のトラフィックを制限する機能のことです。ファイアウォールは、ソフトウェアとハードウェア(ルーターや専用のゲートウェイ・マシンなど)を組み合せて作成できます。ファイアウォールは、プロトコル、リクエストされたサービス、ルーティング情報、および送信元と送信先のホストまたはネットワークに基づいてトラフィックの通過を許可または拒否するフィルタを利用します。また、認証されたユーザーについてもアクセスを許可する場合があります。

図3-4に、WebLogic Serverクラスタ宛てのトラフィックをフィルタ処理するファイアウォールを使った代表的な設定を示します。

図3-4 代表的なファイアウォールの設定

WebLogic Serverでは、ファイアウォールと組み合せて、以下の機能を使用できます。

- 接続フィルタ

- 境界認証

接続フィルタ

WebLogic Server接続フィルタを使用して、プロトコル、IPアドレス、およびDNSノード名に基づいてネットワーク・トラフィックをフィルタ処理するファイアウォールを設定できます。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項を参照してください。

境界認証

IDアサーション・プロバイダを使用して、境界認証 (トークンを使用する特別なタイプの認証)を設定できます。WebLogic Serverのセキュリティ・アーキテクチャは、境界に基づく認証(Webサーバー、ファイアウォール、VPN)を実行し、複数のセキュリティ・トークン・タイプ/プロトコル(SOAP、SAML、SPNEGO、IIOP-CSIv2)を処理するIDアサーション・プロバイダをサポートします。

Java EEとWebLogicセキュリティ

ユーザー認証とユーザー認可を実装および使用するために、WebLogic Serverでは、JDKのセキュリティ・サービスが利用されます。他のJava EEコンポーネントと同様、セキュリティ・サービスも標準化されたモジュール・コンポーネントに基づいています。WebLogic Serverは、標準に従ってこれらのJavaセキュリティ・サービス・メソッドを実装し、細かなアプリケーションの動作をプログラミングを必要とせずに自動的に処理する拡張を追加します。

WebLogic ServerのJavaセキュリティのサポートにより、アプリケーションの開発者は、セキュリティ領域の最新の強化拡張と開発を利用できます。このため、企業投資を主にJavaプログラミング技術に活用できます。定義され、ドキュメントされたJava標準に従うことで、WebLogic Serverのセキュリティ・サポートではJava開発者に対する共通の基準が確立されます。

この節では、以下の内容について説明します。

- Javaセキュリティ・パッケージ

- CSIv2 (Common Secure Interoperability Version 2)

Javaセキュリティ・パッケージ

WebLogic Serverは、次のJava SEおよびJava EE 7セキュリティ・パッケージに準拠し、それらのパッケージをサポートしています。

- JSSE (Java Secure Socket Extension)

- JAAS (Java Authentication and Authorization Service)

- Javaセキュリティ・マネージャ

- Java Cryptography ArchitectureとJCE (Java Cryptography Extension)

- JACC (Java Authorization Contract for Containers)

- Java Authentication Service Provider Interface for Containers (JASPIC)

JSSE (Java Secure Socket Extension)

JSSEは、SSLとTLS v1プロトコルをサポートおよび実装し、それらのプロトコルの機能をプログラムで利用可能にするパッケージのセットです。WebLogic Serverでは、WebLogic Serverクライアント、および他のサーバーとの間で転送されるデータを暗号化するために、Secure Sockets Layer (SSL)がサポートされています。

JAAS (Java Authentication and Authorization Service)

JAASは、ユーザー・ベースの認証およびアクセス制御のためのフレームワークを提供するパッケージのセットです。WebLogic Serverでは、JAASの認証用クラスだけを使用します。

注意:
WebLogic Serverドメインには、JAAS認可(環境に必要な場合)の使用に影響を与えるセキュリティ構成設定があります。これを実行する必要がある場合の詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のJAAS認証を使用するドメインの構成に関する項を参照してください。

JAASは以下の場合に使用されます。

- リモートJavaクライアント認証

- WebコンテナやEJBコンテナ内、およびWebLogic認証プロバイダやIDアサーション・プロバイダ内におけるWebLogic Serverインスタンス間の内部認証

JAASの詳細は、「JAAS (Java Authentication and Authorization Service)」を参照してください。

Javaセキュリティ・マネージャ

Javaセキュリティ・マネージャは、Java仮想マシン(JVM)のセキュリティ・マネージャです。セキュリティ・マネージャは、Java APIと連携しjava.lang.SecurityManagerクラスを通じてセキュリティ境界を定義します。SecurityManagerクラスは、プログラマが各自のJavaアプリケーション用のカスタム・セキュリティ・ポリシーを確立することを可能にします。

Javaセキュリティ・マネージャとWebLogic Serverを一緒に使用すると、JVM内で実行されているWebLogicリソースのセキュリティを強化できます。WebLogic ServerでのJavaセキュリティ・マネージャを使用したWebLogicリソースの保護は、省略可能なセキュリティ手順です。

Javaセキュリティ・マネージャを使用すると、WebLogicリソースを保護するために、以下のセキュリティ・タスクを行うことができます。

- 全体的に使用するweblogic.policyファイルの修正

- EJBおよびリソース・アダプタに対するアプリケーション型のセキュリティ・ポリシーの設定
このタスクは、Javaセキュリティ・ポリシー・ファイルを使用して行います。

- 特定のEJBおよびリソース・アダプタに対するアプリケーション固有のセキュリティ・ポリシーの設定
このタスクは、デプロイメント記述子(weblogic.xml、weblogic-ejb-jar.xml、およびrar.xml)を使用して行います。

Javaセキュリティ・マネージャを使用してこれらのタスクを実行する方法の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティを使用してWebLogicリソースを保護する方法に関する項を参照してください。

Java Cryptography ArchitectureとJCE (Java Cryptography Extension)

これらのセキュリティAPIは、Javaプラットフォーム向けの暗号機能へのアクセスおよび暗号機能の開発と、暗号、鍵の生成と照合、およびMessage Authentication Code (MAC)アルゴリズムの実装の開発に使用するフレームワークを提供します。

WebLogic ServerではこれらのセキュリティAPIが完全にサポートされています。

JACC (Java Authorization Contract for Containers)

JACCは、WebLogic Serverドメイン内のEJBおよびサーブレット・コンテナに代替認可メカニズムを提供します。JACCがコンフィグレーションされている場合、WebLogic Securityフレームワークのアクセス決定、裁決、およびロール・マッピング機能は、EJBおよびサーブレットの認可判定には使用されません。JACCクラスは、ロールとプリンシパルのマッピングだけでなく、アクセス決定を返すためにも使用します。WebLogic Securityフレームワークと一緒にJACCフレームワークを使用することはできません。WebLogic Serverで使用されるJACCクラスには、決定を下すためのポリシー・オブジェクトの実装は含まれません。かわりに、JACCクラスは、Java java.security.Policyオブジェクトに依存します。

Java Authentication Service Provider Interface for Containers (JASPIC)

Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)では、メッセージ認証メカニズムを実装する認証プロバイダを、サーバーWebアプリケーションのメッセージ処理コンテナまたはランタイムに統合できるサービス・プロバイダ・インタフェース(SPI)が定義されています。

JASPICを使用するようにWebアプリケーションのコードを変更する必要はありません。かわりに、WebLogic Server管理コンソールまたはWLSTを使用して、Webアプリケーションのデプロイ後の操作用にJASPICを有効化します。

SAMで作成されたプリンシパルのカスタム検証方法を含む、WebアプリケーションでのJASPICの使用方法の詳細は、WebアプリケーションでのJASPICの使用に関する項を参照してください。

CSIv2 (Common Secure Interoperability Version 2)

WebLogic Serverでは、IIOP (Internet Inter-ORB) (GIOPバージョン1.2)およびCORBA CSIv2 (Common Secure Interoperability version 2)仕様に基づいたEJB (Enterprise JavaBean)相互運用性プロトコルがサポートされています。WebLogic ServerでCSIv2をサポートすることにより、以下のことが可能になります。

- J2EE (Java 2 Enterprise Edition)バージョン1.4.1の参照実装と相互運用できます。

- WebLogic Server IIOPクライアントでT3クライアントの場合と同じようにユーザー名とパスワードを指定できるようになります。

- GSSAPI (Generic Security Services Application Programming Interface)初期コンテキスト・トークンをサポートできるようになります。今回のリリースでは、ユーザー名/パスワードとGSSUP (Generic Security Services Username Password)トークンのみがサポートされています。

注意:
WebLogic ServerにおけるCSIv2実装は、J2EE CTS (Compatibility Test Suite)適合性テストに合格しています。

CSIv2実装への外部インタフェースは、CORBAオブジェクトのユーザー名とパスワードを取得するJAAS LoginModuleです。JAAS LoginModuleは、WebLogic Javaクライアント、あるいは別のJava EEアプリケーション・サーバーに対するクライアントの役目をするWebLogic Serverインスタンスで使用することができます。CSIv2サポート用のJAAS LoginModuleはUsernamePasswordLoginModuleという名前で、weblogic.security.auth.loginパッケージに格納されています。

注意:
WebLogic ServerクラスタのCSIv2のロード・バランシング・サポートに関する詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー・アフィニティおよびCSIv2を使用したIIOPクライアント認証に関する項を参照してください

JASPICセキュリティ

Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)では、メッセージ認証メカニズムを実装する認証プロバイダを、サーバーWebアプリケーションのメッセージ処理コンテナまたはランタイムに統合できるサービス・プロバイダ・インタフェース(SPI)が定義されています。

WebLogic Serverでは、JASPICを使用して、Webアプリケーションに対する認証を構成済認証構成プロバイダに委任できます。

この節では、以下のトピックについて説明します。

- Java Authentication Service Provider Interface for Containers (JASPIC)の概要

- JASPICプログラミング・モデル

Java Authentication Service Provider Interface for Containers (JASPIC)の概要

JASPIC認証構成プロバイダは、Webアプリケーションに対するユーザー資格証明を認証してサブジェクトを返します。これは、受信するWebアプリケーション・メッセージを認証し、そのメッセージ認証の結果確立されたID(予測されるサブジェクト)をWebLogic Serverに返します。つまり、Webアプリケーションに構成された認証構成プロバイダが、そのWebアプリケーションのWLS認証メカニズムのかわりに使用されます。

デフォルトのWebLogic Server認証構成プロバイダで機能する独自のサーバー認証モジュール(SAM)を使用できます。または、独自の認証構成プロバイダとSAMの両方を作成して使用しても構いません。

Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されているように、認証構成プロバイダ(仕様内では「認証コンテキスト構成プロバイダ」)は、javax.security.auth.message.config.AuthConfigProviderインタフェースの実装です。認証構成プロバイダには構成メカニズムがあり、このメカニズムを使用して、登録済のSAMと、未認証アクセスまたは許可されたアクセスからの保護が必要なアプリケーションとのバインディングが定義されます。

注意:
WebLogic ServerはJASPIC 1.1をサポートしています。WebLogic Serverは、サーブレット・プロファイルのみをサポートしています。

SAMは、JASPICに準拠したサーバー側認証モジュールの実装になります。Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されているように、SAMはjavax.security.auth.message.module.ServerAuthModuleインタフェースを実装し、メッセージ処理モデルのあらかじめ決められた時点でWebLogic Serverから起動されます。

WebLogic Serverでは次の操作が可能です。

- ドメイン全体でJASPICを有効または無効にします。JASPICがドメインに対して有効な場合のみ、各WebアプリケーションでJASPICをどのようにサポートするかを決定できます。
ドメインに対してJASPICが無効の場合、アプリケーションの構成に関係なく、JASPICはすべてのWebアプリケーションに対して無効になります。

- ドメイン全体のWebLogic認証構成プロバイダを構成します。これに対し、各自のサーバー認証モジュール(SAM)のクラス名とプロパティを指定します。

- ドメイン全体のカスタム認証プロバイダを構成します。これに対し、このプロバイダのクラス名とそのプロパティを指定します。

- ドメイン内のデプロイされるWebアプリケーションごとに、JASPICを無効にするか(デフォルト)、ユーザー資格証明を認証して有効なサブジェクトを返すように構成された認証構成プロバイダを1つ選択するかを決定します。

JASPICプログラミング・モデル

JASPICプログラミング・モデルについては、Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されています。

SAM実装のサンプルについては、「GlassFishサーブレット・コンテナへの認証メカニズムの追加」を参照してください。GlassFishサーバーの観点で記載されていますが、SAMを作成するためのヒントやSAM用のサンプルは役立ちます。

4 セキュリティ・レルム

この章では、セキュリティ・レルムについて説明します。

この章の内容は次のとおりです。

- セキュリティ・レルムの概要

- ユーザー

- グループ

- セキュリティ・ロール

- セキュリティ・ポリシー

- セキュリティ・プロバイダ

セキュリティ・レルムの概要

セキュリティ・レルムは、WebLogicリソースを保護する複数のメカニズムで構成されています。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます(図4-1を参照)。ユーザーはセキュリティ・レルムで定義されていないと、そのセキュリティ・レルムに属するWebLogicリソースにアクセスできません。ユーザーが特定のWebLogicリソースにアクセスしようとした場合、WebLogic Serverは、関連するセキュリティ・レルムでそのユーザーに割り当てられているセキュリティ・ロールと、その特定のWebLogicリソースのセキュリティ・ポリシーをチェックして、ユーザーを認証および認可します。

図4-1 WebLogic Serverのセキュリティ・レルム

ユーザー

ユーザーとは、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ドメイン全体を対象とするグループとは異なり、WebLogic Serverドメインの単一のアプリケーションに属する特定のWebLogicリソースを対象にできます。

セキュリティ・ロールをユーザーまたはグループに付与すると、付与されている間に限り、定義されたアクセス権限がそのユーザーまたはグループに与えられます。複数のユーザーまたはグループに単一のセキュリティ・ロールを付与することができます。

注意:
WebLogic Server 6.xでは、セキュリティ・ロールはWebアプリケーションとEnterprise JavaBeans (EJB)のみに適用されました。以降のリリースでは、セキュリティ・ロールは、定義されているすべてのWebLogicリソースに対して適用されます。

セキュリティ・ポリシー

セキュリティ・ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間の関連付けです。セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護します。WebLogicリソースは、セキュリティ・ポリシーを作成するまでは保護されません。ポリシー条件とは、セキュリティ・ポリシーを作成する際の条件です。WebLogic Serverによってデフォルトのポリシー条件セットが提供されます。WebLogic Serverには、HTTPサーブレット・リクエストとセッションの属性およびEJBメソッド・パラメータにアクセスするポリシー条件が含まれます。「ポリシー・エディタ」には「時間」と「日付」のポリシーが含まれます。

注意:
セキュリティ・ポリシーは、WebLogic Server 6.xでWebLogicリソースを保護するために使用していたアクセス制御リスト(ACL)にかわるものです。

セキュリティ・プロバイダ

セキュリティ・プロバイダとは、WebLogicリソースを保護するためにアプリケーションにセキュリティ・サービスを提供するモジュールのことです(図4-1を参照)。WebLogic Server製品の一部として提供されるセキュリティ・プロバイダを使用することも、サード・パーティ・セキュリティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することも、独自にカスタム・セキュリティ・プロバイダを開発することもできます。カスタム・セキュリティ・プロバイダの開発方法については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

この節では、以下の内容について説明します。

- セキュリティ・プロバイダ・データベース

- セキュリティ・プロバイダのタイプ

- セキュリティ・プロバイダとセキュリティ・レルム

セキュリティ・プロバイダ・データベース

以下の節では、セキュリティ・プロバイダ・データベースとは何か、セキュリティ・レルムがセキュリティ・プロバイダ・データベースの使用にどのように影響するのかについて説明します。

- セキュリティ・プロバイダ・データベースとは

- セキュリティ・レルムとセキュリティ・プロバイダ・データベース

- 組込みLDAPサーバー

- RDBMSセキュリティ・ストア

セキュリティ・プロバイダ・データベースとは

セキュリティ・プロバイダ・データベースには、一部のセキュリティ・プロバイダがセキュリティ・サービスを提供するために使用するユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明が格納されます(図4-1を参照)。たとえば、認証プロバイダではユーザーとグループについての情報、認可プロバイダではセキュリティ・ポリシーについての情報、ロール・マッピング・プロバイダではセキュリティ・ロールについての情報、資格証明マッピング・プロバイダではリモート・アプリケーションに対して使用する資格証明についての情報が必要になります。これらのセキュリティ・プロバイダが正しく機能するためには、この情報をデータベースでアクセスできるようにする必要があります。

セキュリティ・プロバイダ・データベースとしては、WebLogicセキュリティ・プロバイダで使用されるような組込みLDAPサーバー、Web上で使用できるサンプル・カスタム・セキュリティ・プロバイダで使用されるようなプロパティ・ファイル、またはすでに使用している、顧客側で用意された製品レベルの品質のデータベースを使用できます。

セキュリティ・プロバイダ・データベースは、セキュリティ・プロバイダが最初に使用されるときに初期化する必要があります。(つまりセキュリティ・プロバイダを含むセキュリティ・レルムがデフォルトの(アクティブな)セキュリティ・レルムとして設定される前に)初期化は次の場合に実行できます。

- WebLogic Serverのインスタンスが起動するとき。

- セキュリティ・プロバイダのMBeanの1つが呼び出されるとき。

セキュリティ・プロバイダ・データベースは、少なくとも、WebLogic Serverで提供されるデフォルトのグループ、セキュリティ・ポリシー、セキュリティ・ロールで初期化されます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のセキュリティ・プロバイダとWebLogicリソースに関する項を参照してください。

セキュリティ・レルムとセキュリティ・プロバイダ・データベース

同じセキュリティ・レルムで同じタイプの複数のセキュリティ・プロバイダが構成されている場合、それらのセキュリティ・プロバイダでは同じセキュリティ・プロバイダ・データベースを使用できます。この動作は、Oracle Technology Network (OTN)で入手可能なWebLogicセキュリティ・プロバイダとサンプル・セキュリティ・プロバイダのすべてに当てはまります。

たとえば、デフォルト・セキュリティ・レルム(myrealm)で2つのWebLogic認証プロバイダを構成する場合、それらのWebLogic認証プロバイダは両方とも組込みLDAPサーバーの同じ位置をセキュリティ・プロバイダ・データベースとして使用し、したがって同じユーザーとグループを使用します。さらに、WebLogic認証プロバイダの1つにユーザーまたはグループを追加すると、他のWebLogic認証プロバイダでもそのユーザーまたはグループが表示されます。

注意:
同じタイプの2つのWebLogicセキュリティ・プロバイダ(またはサンプル・セキュリティ・プロバイダ)が2つの異なるセキュリティ・レルムで構成されている場合は、それぞれが独自のセキュリティ・プロバイダ・データベースを使用します。

独自に開発したカスタム・セキュリティ・プロバイダ(またはサード・パーティ・セキュリティ・ベンダーのカスタム・セキュリティ・プロバイダ)は、セキュリティ・プロバイダの各インスタンスが独自のデータベースを使用するように、またはセキュリティ・レルムのすべてのセキュリティ・プロバイダ・インスタンスが同じデータベースを共有するように設計できます。これは、既存のシステムとセキュリティ要件に基づいて決断する必要のある設計上の決定事項です。セキュリティ・プロバイダに関する設計上の決定事項の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の設計上の考慮事項に関する項を参照してください。

組込みLDAPサーバー

WebLogic Serverでは、組込みLDAPサーバーが、WebLogicセキュリティ・プロバイダ用のユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーを格納するデータベースとして使用されます。組込みLDAPサーバーは、適度に小規模な環境(ユーザー数10,000以下)向けの、製品レベルの品質を持つ完全なLDAPサーバーです。この推奨値より大きい規模にする必要のあるアプリケーションでは、組込みLDAPサーバーは、将来的に本番デプロイメント用の外部LDAPサーバーにエクスポートする際の、優秀な開発、統合およびテスト環境として使用できます。組込みLDAPサーバーでは、以下のアクセスおよび格納機能がサポートされています。

- LDAPサーバー内のエントリへのアクセスとエントリの変更

- LDAPブラウザを使用した、LDAPサーバーに対するセキュリティ・データのインポートとエクスポート

- WebLogicセキュリティ・プロバイダによる読込みおよび書込みアクセス

注意:
WebLogic Serverでは、組込みLDAPサーバーへの属性の追加はサポートされていません。

表4-1に、各WebLogicセキュリティ・プロバイダによる組込みLDAPサーバーの使用方法を示します。

表4-1 組込みLDAPサーバーの使用方法

WebLogicセキュリティ・プロバイダ

組込みLDAPサーバーの使用

認証

ユーザーおよびグループ情報を格納します。

IDアサーション

ユーザーおよびグループ情報を格納します。

認可

セキュリティ・ロールおよびセキュリティ・ポリシーを格納します。

裁決

なし。

ロール・マッピング

指定されたWebLogicリソースについてリクエスト側に付与されるロール群を計算によって取得することで、動的ロール関連付けをサポートします。

監査

なし。

資格証明マッピング

ユーザー名/パスワードの資格証明マッピング情報を格納します。

証明書レジストリ

登録されている目的の証明書を格納します。

RDBMSセキュリティ・ストア

WebLogic Serverでは、外部RDBMSを以下のセキュリティ・プロバイダが使用するデータ・ストアとして使用することができます。

- XACML認証プロバイダおよびロール・マッピング・プロバイダ

- WebLogic資格証明マッピング・プロバイダ

- PKI資格証明マッピング・プロバイダ

- SAML 1.1の以下のプロバイダ

- SAML IDアサーション・プロバイダV2

- SAML資格証明マッピング・プロバイダV2

- SAML 2.0の以下のプロバイダ

- SAML 2.0 IDアサーション・プロバイダ

- SAML 2.0資格証明マッピング・プロバイダ

- デフォルトの証明書レジストリ

RDBMSセキュリティ・ストアがセキュリティ・レルム内で構成されているとき、セキュリティ・レルムに作成済みの任意の先行セキュリティ・プロバイダのインスタンスは、データストアとして、組込みLDAPサーバーではなく、RDBMSセキュリティ・ストアのみを自動的に使用します。その他のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します; たとえば、WebLogic認証プロバイダは組込みLDAPサーバーを使用します。

RDBMSセキュリティ・ストアはドメインの作成時に構成することをお薦めします。このプロセスを簡素化するように構成ウィザードが改良されました。これにより、ドメインの起動時にドメインへのアクセスに必要なセキュリティ・ポリシーが外部RDBMSから確実に取得されるようになります。

RDBMSセキュリティ・ストアは、クラスタ環境のようにドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを使用する場合に必要になります。RDBMSセキュリティ・ストアの詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。

セキュリティ・プロバイダのタイプ

以下の節では、WebLogic Serverで使用できるセキュリティ・プロバイダのタイプを説明します。

- 認証プロバイダ

- IDアサーション・プロバイダ

- プリンシパル検証プロバイダ

- 認可プロバイダ

- 裁決プロバイダ

- ロール・マッピング・プロバイダ

- 監査プロバイダ

- 資格証明マッピング・プロバイダ

- 証明書の検索と検証のプロバイダ

注意:
複数のタイプのプロバイダを結合した単一のセキュリティ・プロバイダを開発することはできません。たとえば、認可とロール・マッピングを行う1つのセキュリティ・プロバイダを開発することはできません。

認証プロバイダ

認証プロバイダを使用すると、WebLogic Serverではユーザーを検証することで信頼を確立できます。WebLogic Serverのセキュリティ・アーキテクチャは、ユーザー名とパスワードの認証、証明書とダイジェストの認証(WebLogic Serverを直接用いる)、およびHTTP証明書に基づく認証(外部のWebサーバーを介して行う)を実行する認証プロバイダをサポートします。

注意:
IDアサーション・プロバイダは、境界に基づく認証と複数のセキュリティ・トークン・タイプ/プロトコルを処理する特殊なタイプの認証プロバイダです。

認証プロバイダには、ユーザーまたはシステムの認証を実際に実行するLoginModuleが組み込まれています。認証プロバイダは、プリンシパル(ユーザー/グループ)に対する署名と信頼性の確認によって追加のセキュリティを提供するプリンシパル検証プロバイダも使用します。プリンシパル検証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のプリンシパル検証プロバイダに関する項を参照してください。

セキュリティ・レルムには少なくとも1つの認証プロバイダが必要です。1つのセキュリティ・レルムに複数の認証プロバイダを構成することもできます。複数の認証プロバイダを構成すると、それぞれが異なる認証を実行する複数のLoginModuleを使用できます。管理者は、各認証プロバイダを構成して、ユーザーがシステムにログインするときに複数のLoginModuleがどのように呼び出されるのかを指定します。認証プロバイダは認証で使用されるプリンシパルにセキュリティを追加するので、プリンシパル検証プロバイダは認証プロバイダからアクセス可能である必要があります。

認証プロバイダとLoginModuleの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認証プロバイダに関する項を参照してください。

IDアサーション・プロバイダ

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-CSIv2)を処理できます。Microsoft Passportなどの様々なトークン・タイプをサポートするカスタムIDアサーション・プロバイダを記述することもできます。認証プロバイダのLoginModuleと一緒に使用すると、IDアサーション・プロバイダはシングル・サインオンをサポートします。たとえば、IDアサーション・プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザーは何度もサインオンを求められることはありません。

注意:
X.501およびX.509証明書に対してWebLogic IDアサーション・プロバイダを使用するには、WebLogic Server製品に付属のデフォルトのユーザー名マッパー(weblogic.security.providers.authentication. DefaultUserNameMapperImpl)を使用するか、独自のweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を使用するかのいずれかの方法があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタム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アサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

プリンシパル検証プロバイダ

プリンシパル検証プロバイダは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ・プロバイダです。一部のLoginModuleはRMIクライアントのかわりにリモートで実行することができ、プログラムによるサーバー呼出しから次のサーバー呼び出しまでの間、認証済みのサブジェクトがクライアント・アプリケーション・コードに保持できるので、認証プロバイダはプリンシパル検証プロバイダを利用してそのサブジェクト内に格納されているプリンシパルのセキュリティを保護する追加対策を講じます。

プリンシパル検証プロバイダは、プリンシパルに対する署名と信頼性の確認によってそのようなセキュリティを保護する追加対策を講じます。このプリンシパル検証によって、信頼度は向上し、悪意あるプリンシパルによる改ざんの可能性が低下します。サブジェクトのプリンシパルの検証は、WebLogic Serverで各呼出しのRMIクライアント・リクエストがデマーシャリングされる際に行われます。サブジェクトのプリンシパルの信頼性も、認可判定の際に検証されます。

セキュリティ・レルムには少なくとも1つの認証プロバイダが必要なので、セキュリティ・レルムにはプリンシパル検証プロバイダも1つ必要です。複数の認証プロバイダがある場合は、それぞれに対応するプリンシパル検証プロバイダが必要です。

注意:
WebLogic Server管理コンソールを使用して、プリンシパル検証プロバイダを直接構成することはできません。WebLogic Serverによって認証プロバイダの構成時に、必要なプリンシパル検証プロバイダが構成されます。

プリンシパル検証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のプリンシパル検証プロバイダに関する項を参照してください。

認可プロバイダ

認可プロバイダは、ユーザーまたはグループに付与されたセキュリティ・ロールと、要求されたWebLogicリソースに割り当てられたセキュリティ・ポリシーに基づいてWebLogicリソースへのアクセスを制御します。WebLogicリソース、セキュリティ・ロール、およびセキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 を参照してください。

認可プロバイダの中には、アクセス決定があります。アクセス決定は、WebLogicリソースに対して特定の操作を実行する権限がサブジェクトにあるかどうかを実際に判断します。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のプリンシパル検証プロバイダに関する項を参照してください。

セキュリティ・レルムには少なくとも1つの認可プロバイダが必要であり、セキュリティ・レルムで複数の認可プロバイダを構成することもできます。複数の認可プロバイダを構成すると、より高度なモジュール設計に従うことができます。たとえば、WebアプリケーションおよびEnterprise JavaBean (EJB)の権限を処理する1つの認可プロバイダを持ち、その他の種類のWebLogicリソースの権限を処理するもう1つのプロバイダを持つことが可能です。別の例としては、1つの認可プロバイダが国内の従業員を処理し、もう1つのプロバイダは海外の従業員の権限を処理できます。

WebLogic Serverには、以下に示すバルク・アクセス・バージョンの認可プロバイダSSPIインタフェースがあります。

- BulkAuthorizationProvider

- BulkAccessDecision

バルク・アクセスSSPIインタフェースを使用すると、認可プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。

認可プロバイダとアクセス決定の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認可プロバイダに関する項を参照してください。

裁決プロバイダ

認可プロバイダの一部として、アクセス決定は特定のWebLogicリソースにアクセスするための許可がサブジェクトにあるかどうかを判断します。したがって、複数の認可プロバイダが構成されている場合は、「アクセス可能か」の問いに対してそれぞれが異なる回答を返す可能性があります。この回答は、PERMIT、DENY、ABSTAINのいずれかです。複数の認可プロバイダのアクセス決定の回答が一致しない場合にどうするかを決定するのは、裁決プロバイダの主な役割です。裁決プロバイダは、各アクセス決定の回答を比較検討し最終結果を返すことで認可上の競合を解消します。認可プロバイダが1つのみ、裁決プロバイダがない場合、その1つの認可プロバイダのアクセス決定から返されるABSTAINはDENYのように処理されます。

注意:
WebLogic裁決プロバイダでは、WebLogic Server管理コンソールを使用して、決定の放棄を許可または拒否のいずれとして処理するかを制御できます。

裁決プロバイダは、構成されている認可プロバイダが複数の場合のみセキュリティ・レルムで構成する必要があります。セキュリティ・レルムで構成できる裁決プロバイダは1つだけです。

注意:
デフォルトのセキュリティ・レルムには認可プロバイダが1つしかないので、裁決プロバイダが提供されていても必要ありません。

WebLogic Serverには、以下に示すバルク・アクセス・バージョンの裁決プロバイダSSPIインタフェースがあります。

- BulkAdjudicationProvider

- BulkAdjudicator

バルク・アクセスSSPIインタフェースを使用すると、裁決プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。

裁決プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の裁決プロバイダに関する項を参照してください。

ロール・マッピング・プロバイダ

ロール・マッピング・プロバイダでは、指定されたWebLogicリソースについてリクエスト側に付与されるセキュリティ・ロール群を計算によって取得することで、動的ロール関連付けをサポートします。WebLogicセキュリティ・フレームワークは、特定のWebLogicリソースにアクセスする必要があるときに特定のサブジェクトにどのセキュリティ・ロールが適用されるのかを以下のようにして判断します。

- Java EEおよびWebLogicデプロイメント記述子ファイルからセキュリティ・ロールを取得する

- ビジネス・ロジックおよび現在の操作パラメータを使用してセキュリティ・ロールを判断する

ロール・マッピング・プロバイダから認可プロバイダにこのセキュリティ・ロール情報が提供されるので、認可プロバイダは、ロール・ベースのセキュリティを用いるWebLogicリソース(すなわち、WebアプリケーションやEnterprise JavaBeanコンテナのリソース)に「アクセスできるか」という質問に答えることができます。

セキュリティ・ロールはJava EEデプロイメント記述子に設定するか、WebLogic Server管理コンソールを使って作成します。デプロイメント記述子に設定されたセキュリティ・ロールはデプロイ時に適用されます(デプロイメント記述子を無視することにした場合を除く)。

セキュリティ・レルムには少なくとも1つのロール・マッピング・プロバイダが必要であり、セキュリティ・レルムで複数のロール・マッピング・プロバイダを構成することもできます。複数のロール・マッピング・プロバイダを構成すると、従来のインフラストラクチャ要件の範囲内で作業することも(たとえばユーザーおよびセキュリティ・ロールの情報が含まれる各LDAPサーバーにつき1つのロール・マッピング・プロバイダを構成する)、または高度なモジュール設計に従うこともできます(たとえばWebアプリケーションおよびEnterprise JavaBeans (EJB)のマッピングを処理するロール・マッピング・プロバイダと、他のタイプのWebLogicリソースのマッピングを処理する別のロール・マッピング・プロバイダを構成する)。

注意:
複数のロール・マッピング・プロバイダが構成されている場合には、WebLogicセキュリティ・フレームワークは、そのすべてのロール・マッピング・プロバイダから返されるセキュリティ・ロール群の論理積を取ります。つまり、すべてのロール・マッピング・プロバイダからのセキュリティ・ロール名が、重複を削除して1つのリストに結合されます。

WebLogic Serverには、以下に示すバルク・アクセス・バージョンのロール・マッピング・プロバイダSSPIインタフェースがあります。

- BulkRoleProvider

- BulkRoleMapper

バルク・アクセスSSPIインタフェースを使用すると、ロール・マッピング・プロバイダにおいて、1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測することが可能になります。

ロール・マッピング・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のロール・マッピング・プロバイダに関する項を参照してください。

監査プロバイダ

監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布します。監査プロバイダは、特定の監査基準(重大度など)に基づいて特定のイベントを監査するかどうかを決定します。また、監査プロバイダはLDAPディレクトリ、データベース、シンプル・ファイルなどの出力リポジトリに監査情報を書き込むことができます。セキュリティ担当者の呼び出しなどの特定のアクションも監査プロバイダの一部として構成することができます。

他のタイプのセキュリティ・プロバイダ(認証や認可など)は、WebLogicセキュリティ・フレームワークを介して呼出しを行うことによって、セキュリティ操作の実行前と実行後に監査サービスをリクエストできます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタム・セキュリティ・プロバイダからのイベントの監査に関する項を参照してください。

監査プロバイダはセキュリティ・レルムで複数を構成できますが、必須ではありません。

監査プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の監査プロバイダに関する項を参照してください。

資格証明マッピング・プロバイダ

資格証明マップは、WebLogic Serverで使用される資格証明から、レガシー・システムまたはリモート・システムで使用される資格証明へのマッピングであり、そのシステムの特定のリソースへの接続方法をWebLogic Serverに指示します。つまり、資格証明マップを使用することで、WebLogic Serverが、認証済みのサブジェクトにかわってリモート・システムにログインできるようになります。

資格証明マッピング・プロバイダでは、ユーザー名とパスワードの組合せ、SAMLアサーション、公開鍵証明書、別名と資格証明タイプの組合せといった複数種の資格証明を処理できます。資格証明マッピングはデプロイメント記述子で設定しても、WebLogic Server管理コンソールを使用して設定してもかまいません。これらの資格証明マッピングはデプロイ時に適用されます(それらの資格証明マッピングを無視することにした場合を除く)。

セキュリティ・レルムには少なくとも1つの資格証明マッピング・プロバイダが必要であり、セキュリティ・レルムで複数の資格証明マッピング・プロバイダを構成することもできます。複数の資格証明マッピング・プロバイダが構成されている場合、WebLogicセキュリティ・フレームワークは各資格証明マッピング・プロバイダを巡回して、コンテナでリクエストされている種類の資格証明が含まれているかどうかを検索します。その後、WebLogicセキュリティ・フレームワークはすべての資格証明を蓄積してから、リストとして返します。

注意:
WebLogic Serverでは、SAML 1.1用とSAML 2.0用に別々の資格証明マッピング・プロバイダが用意されています。それらのプロバイダのそれぞれのSAMLバージョンを入れ替えることはできません。SAML資格証明マッピング・プロバイダV2はSAML 1.1アサーションのみを生成し、SAML 2.0 ID資格証明マッピング・プロバイダはSAML 2.0アサーションのみを生成します。

資格証明マッピング・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の資格証明マッピング・プロバイダに関する項を参照してください。

証明書の検索と検証のプロバイダ

証明書の検索と検証のプロバイダは、証明書のパスを完了させ、X509証明書チェーンを検証します。CLVプロバイダには、2つのタイプがあります。

- 証明書パス・ビルダー - Webサービスまたはアプリケーション・コードから、証明書、証明書チェーン、または証明書への参照(チェーン内の目的の証明書、または証明書のサブジェクトDN)を受け取ります。このプロバイダが、チェーン内の証明書を検索および検証します。

- 証明書パス検証プロバイダ - SSLプロトコル、Webサービス、またはアプリケーション・コードから証明書チェーンを受け取り、追加の検証(失効チェックなど)を実行します。

証明書パス・ビルダーと証明書パス検証プロバイダは、セキュリティ・レルムに少なくとも1つずつ構成する必要があります。1つのセキュリティ・レルムに、複数の証明書パス検証プロバイダを構成することもできます。複数のプロバイダを構成した場合は、すべての証明書パス検証プロバイダの検証が正常に終了しないと、証明書または証明書チェーンは有効になりません。

WebLogic Serverでは、CLVプロバイダの機能をWebLogic証明書パス・プロバイダと証明書レジストリで提供します。

セキュリティ・プロバイダのまとめ

表4-2に、1つのセキュリティ・レルムで同じタイプの複数のセキュリティ・プロバイダを構成できるかどうかを示します。

表4-2 同一のセキュリティ・レルムにおける同じタイプの複数のセキュリティ・プロバイダ

タイプ

複数のプロバイダがサポートされているか

認証プロバイダ

はい

IDアサーション・プロバイダ

はい

プリンシパル検証プロバイダ

はい

認可プロバイダ

はい

裁決プロバイダ

いいえ

ロール・マッピング・プロバイダ

はい

監査プロバイダ

はい

資格証明マッピング・プロバイダ

はい

証明書の検索と検証のプロバイダ

1つの証明書パス・ビルダー

複数の証明書パス検証プロバイダ

セキュリティ・プロバイダとセキュリティ・レルム

すべてのセキュリティ・プロバイダは、セキュリティ・レルムのコンテキスト内に存在します。WebLogic Serverのセキュリティ・レルムはデフォルト・レルム(myrealmと呼ばれるアクティブなセキュリティ・レルム)として初期状態で定義されていて、図4-2に示されているWebLogicセキュリティ・プロバイダが含まれています。

図4-2 セキュリティ・レルムのWebLogicセキュリティ・プロバイダ

セキュリティ・プロバイダはWebLogic Serverセキュリティ・レルムに「プラグイン」される個別のモジュールまたはコンポーネントなので、手間をかけずに追加、置換、または削除できます。WebLogicセキュリティ・プロバイダ、独自に開発したカスタム・セキュリティ・プロバイダ、サード・パーティ・セキュリティ・ベンダーのセキュリティ・プロバイダ、または以上3つの組合せを使用して完全に機能するセキュリティ・レルムを作成できます。ただし、図4-2にも示すように、一部のタイプのセキュリティ・プロバイダはセキュリティ・レルムが正しく機能する上で必須の要素です。表4-3は、セキュリティ・レルムが完全に機能するためにどのセキュリティ・プロバイダを構成しなければならないかを説明しています。

表4-3 セキュリティ・レルムのセキュリティ・プロバイダ

タイプ

必須?

認証プロバイダ

はい

IDアサーション・プロバイダ

境界認証を使用する場合は「はい」

プリンシパル検証プロバイダ

はい

認可プロバイダ

はい

裁決プロバイダ

複数の認可プロバイダが構成されている場合は「はい」

ロール・マッピング・プロバイダ

はい

監査プロバイダ

いいえ

資格証明マッピング・プロバイダ

はい

証明書の検索と検証のプロバイダ

はい

セキュリティ・レルムの詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のWebLogicセキュリティの構成の主な手順に関する項を参照してください。

5 WebLogicセキュリティ・サービスのアーキテクチャ

この章では、WebLogicセキュリティ・サービスのアーキテクチャについて説明します。このアーキテクチャは3つの主要なコンポーネントで構成されています。

この章の内容は次のとおりです。

- WebLogicセキュリティ・フレームワーク

- WebLogicセキュリティ・フレームワークによるシングル・サインオン

- WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- WebLogicセキュリティ・プロバイダ

WebLogicセキュリティ・フレームワーク

図5-1に、WebLogicセキュリティ・フレームワークの概観を示します。フレームワークは、weblogic.security.serviceパッケージのインタフェース、クラス、および例外で構成されます。

図5-1 WebLogicセキュリティ・サービスのアーキテクチャ

WebLogicセキュリティ・フレームワークの主な役割は、簡素化されたアプリケーション・プログラミング・インタフェース(API)を提供することです。APIは、セキュリティ・サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。そのコンテキスト内でWebLogicセキュリティ・フレームワークは、WebLogicコンテナ(WebおよびEJB)、リソース・コンテナ、セキュリティ・プロバイダの間の仲介役としても機能します。

以下の節では、WebLogicセキュリティ・フレームワークを介したWebLogicコンテナ、リソース・コンテナ、各セキュリティ・プロバイダの間の対話について説明します。

- 認証プロセス

- IDアサーション・プロセス

- プリンシパル検証プロセス

- 認可プロセス

- 裁決プロセス

- ロール・マッピング・プロセス

- 監査プロセス

- 資格証明マッピング・プロセス

- 証明書の検索と検証のプロセス

認証プロセス

図5-2に、ファット・クライアント・ログインの認証プロセスを示します。JAASはサーバー上で動作してログインを実行します。シン・クライアント・ログイン(Webブラウザ・クライアント)の場合でも、JAASはサーバー上で動作します。

図5-2 認証プロセス

注意:
JAASプロセスを直接扱うのは、カスタム認証プロバイダの開発者だけです。クライアント・アプリケーションは、JNDI初期コンテキストまたはJAASのいずれかを使用してユーザー名とパスワードを受け渡します。

ユーザーがユーザー名とパスワードの組合せを使用してシステムにログインしようとすると、WebLogic Serverはそのユーザーのユーザー名とパスワードを検証することによって信頼を確立し、JAASの要件に従って、プリンシパルが格納されたサブジェクトを返します。図5-2で示されているとおり、このプロセスにはLoginModuleとプリンシパル検証プロバイダの使用が必要になります。プリンシパル検証プロバイダの詳細は、「WebLogicプリンシパル検証プロバイダ」を参照してください。

呼出し側のIDの確認に成功すると、認証コンテキストが確立され、IDが確認されたユーザーまたはシステムに関しては、そのコンテキストを通じて他のエンティティに対する認証を行うことができます。認証コンテキストはまた、アプリケーション・コンポーネントに委託することもでき、それによって、そのコンポーネントは別のアプリケーション・コンポーネントを呼び出しつつ、元の呼出し側として動作できるようになります。

IDアサーション・プロセス

IDアサーション・プロバイダは、境界認証プロセスの一部として使用されます。境界認証が使用される場合(図5-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インタフェースの実装を使用するかのいずれかの方法があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「カスタムIDアサーション・プロバイダを開発する必要があるか」を参照してください。

図5-3 境界認証

図5-3でも示されているように、境界認証では認証プロセスと同じ構成要素が必要ですが、IDアサーション・プロバイダも追加されます。

プリンシパル検証プロセス

図5-4に示すとおり、ユーザーはユーザー名とパスワードの組み合わせを使ってシステムにログインしようとします。WebLogic Serverは、構成済みの認証プロバイダのLoginModuleを呼び出すことによって信頼を確立します。LoginModuleは、ユーザーのユーザー名とパスワードを検証し、JAASの要件に従って、プリンシパルが格納されたサブジェクトを返します。

図5-4 プリンシパル検証プロセス

WebLogic Serverは、指定されたプリンシパル検証プロバイダにサブジェクトを渡します。プリンシパル検証プロバイダは、そのプリンシパルに署名して、それらをWebLogic Serverを通じてクライアント・アプリケーションに返します。他のセキュリティ操作のためにサブジェクト内のプリンシパルが必要になった場合、同じプリンシパル検証プロバイダが、そのプリンシパルが署名時から変更されていないかどうかを検証します。

認可プロセス

図5-5に、認可プロセスにおける認可プロバイダ(および関連する裁決プロバイダとロール・マッピング・プロバイダ)とWebLogicセキュリティ・フレームワークとの対話を示します。

図5-5 認可プロセス

ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとすると、認可プロセスが開始されます。要求されたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。リソース・コンテナは、WebLogicセキュリティ・フレームワークを呼び出して、リクエストのサブジェクト、要求されているWebLogicリソースなどの情報を含むリクエスト・パラメータを渡します。WebLogicセキュリティ・フレームワークは、構成済みのロール・マッピング・プロバイダを呼び出して、ロール・マッピング・プロバイダが使用できる形式でリクエスト・パラメータを渡します。ロール・マッピング・プロバイダは、リクエスト・パラメータを使用して、要求側のサブジェクトが資格を有する一連のロールを計算し、該当するロールをWebLogicセキュリティ・フレームワークに渡します。認可プロバイダは、そのサブジェクトがWebLogicリソースに対してリクエストされたアクションを実行できる資格があるかどうかを判別します(つまり、アクセス決定を行います)。複数の認可プロバイダが構成されている場合には、WebLogicセキュリティ・フレームワークは、認可プロバイダから返されたアクセス決定に競合があった場合、その調停を裁決プロバイダに委託します。裁決プロバイダでは、認可判定の最終結果を決定します。

裁決プロセス

複数の認可プロバイダが構成されている場合(図5-5を参照)には、複数のアクセス決定を調停し、判定するための裁決プロバイダが必要になります。裁決プロバイダはTRUEかFALSEの判定を認可プロバイダに返し、認可プロバイダはその判定をWebLogicセキュリティ・フレームワークを通してリソース・コンテナに転送します。

- 判定がTRUEの場合、リソース・コンテナはリクエストを保護ターゲットのWebLogicリソースにディスパッチします。

- 判定がFALSEの場合、リソース・コンテナはセキュリティ例外をスローします。この例外は、リクエスト側にはリクエストしたアクセスを保護されたWebLogicリソースに対して行う権限がなかったことを示します。

ロール・マッピング・プロセス

WebLogicセキュリティ・フレームワークは、認可判定の一環として、セキュリティ・レルム用に構成されている各ロール・マッピング・プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。

動的なロール関連付けを作成する場合のロール・マッピング・プロバイダとWebLogicセキュリティ・フレームワークとの対話を図5-6に示します。

図5-6 ロール・マッピング・プロセス

ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとすると、ロール・マッピング・プロセスが開始されます。要求されたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。リソース・コンテナは、WebLogicセキュリティ・フレームワークを呼び出して、リクエストのサブジェクト、要求されているWebLogicリソースなどの情報を含むリクエスト・パラメータを渡します。WebLogicセキュリティ・フレームワークは、適用するロールのリストを取得するために、構成済みの各ロール・マッピング・プロバイダを呼び出します。要求側に特定のロールの資格があるとセキュリティ・ポリシーに指定されている場合には、そのロールがサブジェクトに適用されるロールのリストに追加されます。このプロセスは、WebLogicリソースまたはリソース・コンテナに適用されるセキュリティ・ポリシーがすべて評価されるまで続行されます。ロールのリストはWebLogicセキュリティ・フレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。

ロール・マッピング・プロバイダによる動的ロール関連付けの結果、一連のロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのロールを用いて、保護ターゲットWebLogicリソース、リソース・コンテナ、およびアプリケーション・コードについての認可判定が行われます。たとえば、Enterprise JavaBean (EJB)であれば、アクセスを許可するかどうかを決めるビジネス・ポリシーを知らなくても、Java EEのisCallerInRole()メソッドを用いてデータベース内のレコードからフィールドを取得することができます。

監査プロセス

図5-7に、監査プロバイダがWebLogicセキュリティ・フレームワークと他のタイプのセキュリティ・プロバイダ(ここでは認証プロバイダ)と対話する仕組みを示します。

図5-7 監査プロセス

リソース・コンテナが、ログイン・リクエストの一部としてユーザーの認証情報(ユーザー名とパスワードの組合せなど)をWebLogicセキュリティ・フレームワークに渡すと、監査プロセスが開始されます。WebLogicセキュリティ・フレームワークは、ログイン・リクエストに関連付けられている情報を構成済みの認証プロバイダに渡します。認証プロバイダが認証サービスを提供するほかに監査イベントをポストする場合、認証プロバイダはAuditEventオブジェクトをインスタンス化します。AuditEventオブジェクトには、監査対象のイベント・タイプや監査の重大度レベルなどの情報が含まれます。その後、認証プロバイダはWebLogicセキュリティ・フレームワーク内の監査サービスを呼び出して、AuditEventオブジェクトを渡します。監査サービスは、AuditEventオブジェクトを構成済みの監査プロバイダの実行時クラスに渡し、監査イベントの記録を有効にします。監査プロバイダの実行時クラスは、AuditEventオブジェクトから取得した情報を使用して監査レコードの内容を管理します。AuditEventオブジェクト内に認証プロバイダによって指定された監査条件が満たされると、該当する監査プロバイダの実行時クラスは監査レコードを書き出します。監査プロバイダの実装によっては、監査記録をファイルやデータベースなどの永続ストレージ・メディアに書き込むことができます。

資格証明マッピング・プロセス

資格証明マッピング・プロセスにおける資格証明マッピング・プロバイダとWebLogicセキュリティ・フレームワークとの対話を図5-8に示します。

図5-8 資格証明マッピング・プロセス

JavaServer Page (JSP)、サーブレット、Enterprise JavaBeans (EJB)、リソース・アダプタなどのアプリケーション・コンポーネントが、エンタープライズ情報システム(EIS) (たとえば、Oracle、SQL Serverなどのリレーショナル・データベース)にアクセスするために、適切なリソース・コンテナを通じてWebLogicセキュリティ・フレームワークを呼び出すと、資格証明マッピング・プロセスが開始されます。呼出しの中で、アプリケーション・コンポーネントは、サブジェクト(「誰が」リクエストしているのか)、WebLogicリソース(「何を」リクエストしているのか)、およびWebLogicリソースにアクセスするために必要な資格証明のタイプについての情報を渡します。WebLogicセキュリティ・フレームワークは、資格証明に対するアプリケーション・コンポーネントのリクエストを、アプリケーション・コンポーネントが必要としている資格証明のタイプを処理する構成済資格証明マッピング・プロバイダに送信します。資格証明マッピング・プロバイダは、そのデータベースを照会して、アプリケーション・コンポーネントがリクエストしているものに一致する資格証明群を取得し、WebLogicセキュリティ・フレームワークに資格証明を返します。WebLogicセキュリティ・フレームワークは、リソース・コンテナを通じてリクエスト側のアプリケーション・コンポーネントに資格証明を返します。アプリケーション・コンポーネントは、資格証明を使用して外部システムにアクセスします。

証明書の検索と検証のプロセス

証明書の検索と検証のプロセスでは、証明書パス・ビルダー、証明書パス検証プロバイダ、証明書検索および検証(CLV)フレームワークの3つが対話します。

次に、証明書チェーンの作成プロセスを示します。

1. WebLogic Webサービスまたはアプリケーション・コードから、証明書チェーンと証明書パス・セレクタ(目的の証明書、サブジェクトDN、発行者DNとシリアル番号、およびサブジェクト・キー識別子のいずれか)がCLVフレームワークに渡されます。

2. 証明書チェーンを検索して検証するため、CLVフレームワークが証明書パス・ビルダーを呼び出します。Webサービスを使用している場合は、CLVフレームワークが信頼性のあるCAのサーバーのリストをプロバイダに渡します。アプリケーション・コードは、信頼性のあるCAのリストをプロバイダに渡します。

3. 証明書チェーンを検索および検証したら、CLVフレームワークがセキュリティ・レルムに構成されている証明書パス検証プロバイダを構成された順に呼び出します。
証明書パス・ビルダーと、構成されているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。

4. CLVフレームワークが、リクエスト側に証明書チェーンを返します。

5. 処理を続行します。

次に、証明書チェーンの検証プロセスを示します。

1. SSLプロトコル、WebLogic Webサービス、またはアプリケーション・コードから、証明書チェーンと証明書パス・セレクタ(目的の証明書、サブジェクトDN、発行者DNとシリアル番号、およびサブジェクト・キー識別子のいずれか)がCLVフレームワークに渡されます。

2. CLVフレームワークによって、証明書チェーンの呼出しが順序付けされており、チェーン内の各証明書が次の証明書を署名していることが確認されます。

3. 証明書チェーンを検証したら、CLVフレームワークがセキュリティ・レルムに構成されている証明書パス検証プロバイダを構成された順に呼び出します。
構成されているすべての証明書パス検証プロバイダが正常に検証を完了した場合にのみ、証明書チェーンが有効になります。エラーが発生した場合は検証が停止します。

4. CLVフレームワークが、リクエスト側に証明書チェーンを返します。

5. 処理を続行します。

WebLogicセキュリティ・フレームワークによるシングル・サインオン

SAMLおよびWindows統合ログイン機能は、WebLogic ServerアプリケーションにWebベースのシングル・サインオン(SSO)機能を提供します。以下の節では、シングル・サインオンの間に行われるWebLogicコンテナ、セキュリティ・プロバイダ、WebLogicセキュリティ・フレームワークの間の対話について説明します。

- SAML 1.1を使用したシングル・サインオン

- SAML 2.0を使用したシングル・サインオン

- デスクトップSSOのプロセス

SAML 1.1を使用したシングル・サインオン

次の節では、SAML 1.1サービスで構成した場合のWebLogic Serverインスタンスの動作について説明します。

- SAML 1.1ソース・サイトとして動作するWebLogic Server

- SAML 1.1宛先サイトとして動作するWebLogic Server

SAML 1.1ソース・サイトとして動作するWebLogic Server

SAMLソースとして動作するとは、以下の動作を意味します。

- 有効なSAMLアサーションを生成します。このアサーションではソース・ドメインがユーザーを認証したことをアサートし、SAMLソース・サイトでユーザーを認識するための名前を提供します。必要に応じて、ユーザーがメンバーになっているローカル(ソース・サイト)グループの名前も提供されます。

- SAML ITSおよびSAMLアサーション検索サービス(ARS)を提供します。

WebLogic Serverは、SAML ITSおよびARSとして動作できます。これらのサービスは、WebLogic Server管理コンソールの「サーバー」→「構成」→「フェデレーテッド・サービス」ページの構成設定に基づいてデプロイされるサーブレットによって提供されます。

SAML ITSサービスでは、V1 SAMLプロバイダのPOSTとアーティファクト・プロファイルのぞれぞれに別のURLが必要です。V2 SAMLプロバイダの場合はPOSTとアーティファクト・プロファイルに別個のURLを用意する必要はありません。

以下の節では、POSTプロファイルおよびアーティファクト・プロファイルで、WebLogic ServerをSAMLソースとして使用する方法について説明します。

POSTプロファイル

POSTプロファイルの仕組みは次のとおりです。

1. ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its)にアクセスします。

2. SAML ITSサーブレットでSAML資格証明マッピング・プロバイダが呼び出され、bearerアサーションがリクエストされます。

3. SAML資格証明マッピング・プロバイダからアサーションが返されます。SAML資格証明マッピング・プロバイダからは、SAML宛先サイトのURLと適切なPOSTフォームへのパスも返されます。

4. SAML ITSサーブレットで、生成されたアサーションを含む署名済みSAMLレスポンスが生成され、これが署名されてbased64でエンコードされた上で、HTMLフォーム(デフォルトまたはカスタム)に組み込まれます。

5. SAML ITSサーブレットから、ユーザーのブラウザにフォームが返されます。

6. ユーザーのブラウザから、宛先サイトのACSにフォームがPOSTされます。

7. アサーションの検証が正常に終了すると、ユーザーがログインしてターゲットにリダイレクトされます。

アーティファクト・プロファイル

アーティファクト・プロファイルの仕組みは次のとおりです。

1. ユーザーが、SAMLソース・サイトのWebサイト(www.weblogic.com)にアクセスします。

2. SAMLサイト間転送サービス(ITS)サーブレットから、必要なアサーション・タイプ(アーティファクト)を渡してSAML資格証明マッピング・プロバイダが呼び出され、アサーションがリクエストされます。

3. SAML資格証明マッピング・プロバイダからアサーションが返されます。SAML資格証明マッピング・プロバイダからは、宛先アサーション・コンシューマ・サービス(ACS)のURLとアサーションIDも返されます。

4. SAML ITSサーブレットは、アサーションIDとローカル・ソース・サイトのソースIDを基にアーティファクトを生成します。(この値は、フェデレーション・サービスのソース・サイト・ページで構成されるソース・サイトURLから計算されます。)

5. SAML ITSサーブレットが、アーティファクトを問合せパラメータとして渡して、ユーザーをSAML宛先サイトのアサーション・コンシューマ・サービス(ACS)にリダイレクトします。

6. ACSが問合せパラメータからアーティファクトを取得し、アーティファクトをデコードしてソースIDを取得します。次に、このソースIDを使用して、SAMLソース・サイトのアサーション検索サービス(ARS)のURLをルックアップします。続いて、SAMLソース・サイトのARSのURLにリクエストを送信して、アーティファクトに対応するアサーションをリクエストします。

7. SAMLアサーション検索サービス(ARS)が、受信したアサーション・リクエストに応答します。その際、アーティファクトを使用して対応するアサーションをアサーション・ストア内で検索し、見つかった場合はSAML宛先サイトへアサーションを返します。

8. アサーションの検証が正常に終了すると、ユーザーがログインしてターゲットにリダイレクトされます。

SAML 1.1宛先サイトとして動作するWebLogic Server

セキュリティ・レルムで認証メカニズムとしてSAMLが構成されており、認証されていないWebブラウザまたはHTTPクライアントが保護されているWebLogicリソースにアクセスしようとすると、WebLogic ServerがSAML宛先サイトとして動作します。

SAML宛先サイトは、サーブレット認証フィルタ(SAML認証フィルタ)として実装され、その構成に基づいてSAML IDアサーション・プロバイダによってデプロイされます。SAML宛先サイトは、構成されている1つまたは複数のURLで受信したアサーションをリスニングします。これらのURLは、アサーション・コンシューマ・サービス(ACS)を提供します。また、SAML宛先サイトは、認証されていないユーザーをリモートSAMLソース・サイトにリダイレクトして、アクセスしようとした特定のURLに基づいて認証を行えるように構成することができます。

以下の節では、POSTプロファイルおよびアーティファクト・プロファイルで、WebLogic ServerをSAML宛先として使用する方法について説明します。

POSTプロファイル

一般的なSSOのシナリオにおけるPOSTプロファイルの仕組みは次のとおりです。

1. ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its)にアクセスします。

2. SAMLソース・サイトでユーザーが認証されアサーションが生成されて、署名済みSAMLレスポンス内にアサーションが格納されたPOSTフォームがユーザーのブラウザに返されます。

3. ユーザーのブラウザから、POSTフォームがSAML宛先サイトのACSにポストされます。ACSで、着信したリクエストのフォーム・パラメータとしてアサーション側ID (APID)が検索され、そのIDを使用して構成がルックアップされてから、他の処理が実行されます。

4. SAML宛先サイトでは、SAMLソース・サイトからPOSTフォームを受け取ると、POSTフォームに組み込まれたSAMLレスポンスを抽出し、レスポンスへの署名に使用する証明書の信頼を検証します。構成によっては、必要に応じて受信者チェックが実行されます。

5. SAMLアサーション・フィルタでは、このアサーションが以前に使用されていないかどうかも確認されます。使用済みチェックが構成されていると、フィルタではアサーションがすでに使用されたかどうかがチェックされます。そうである場合、フィルタはエラーを返します。そうでない場合は、フィルタは後でチェックできるようにアサーションを保持します。

6. 次のいずれかが発生します。

- 使用済みチェックまたは他の有効性/信頼性チェックに失敗した場合は、ログインが失敗し、WebLogic Serverが403 Forbiddenエラーを返します。

- 使用済みチェックおよび他の有効性/信頼性チェックが成功した場合は、ユーザーがログインします(assertIdentity()呼出しによって)。SAML認証フィルタでユーザーのセッションが作成され、認証済みとなったユーザーがリクエストされたターゲットURLにリダイレクトされます。

アーティファクト・プロファイル

アーティファクト・プロファイルの仕組みは次のとおりです。

1. ユーザーが、SAMLソース・サイトのWebサイト(たとえばhttp://www.weblogic.com/samlits/its)にアクセスします。

2. リクエストがSAML ITSサービスにリダイレクトされます。

3. SAMLソース・サイトでユーザーが認証されます。

4. ユーザーが認証されると、SAML ITSでアサーションが生成され、続いてbase-64でエンコードされたアーティファクトが生成されます。このアーティファクトには、SAML ITSのアサーションIDとソースIDが含まれます。

5. SAML ITSにより、アーティファクトがリダイレクトURLの問合せパラメータとして渡され、ユーザーがSAML宛先サイトのアサーション・コンシューマ・サービス(ACS)にリダイレクトされます。ACSで、着信したリクエストの問合せパラメータとしてアサーション側ID (APID)が検索され、そのIDを使用して構成がルックアップされてから、他の処理が実行されます。ACSでは、この問合せパラメータを検索してアーティファクトを取得します。

6. SAML認証フィルタでアーティファクトがbase64でデコードされ、SAMLソース・サイトのソースIDとアサーションIDが特定されます。ソースIDは、そのソース・サイトのアサーション検索URLのルックアップに使用されます。続いてフィルタでは、アーティファクトの送信と対応するアサーションのリクエストを行うSOAPリクエストが、SAMLソース・サイトのアサーション検索サービス(ARS)に対して発行しされます。

7. SAMLソース・サイトからアサーションが返されます。

8. SAML認証フィルタでPrincipalValidatorを呼び出してユーザーのIDがアサートされます。

9. 次のいずれかが発生します。

- 有効性/信頼性チェックに失敗した場合は、ログインが失敗し、WebLogic Serverから403 Forbiddenエラーが返されます。

- 有効性/信頼性チェックが成功した場合は、ユーザーがログインします(assertIdentity()呼出しによって)。SAML認証フィルタでユーザーのセッションが作成され、認証済みとなったユーザーがリクエストされたターゲットURLにリダイレクトされます。

SAML 2.0を使用したシングル・サインオン

WebLogic ServerでサポートされるSAML 2.0 Webシングル・サインオン(SSO)プロファイルは、HTTPリダイレクト、HTTP POST、およびHTTPアーティファクト・バインディングとともに認証リクエスト・プロトコルを実装します。次の節では、このプロファイルを開始できる以下の2つの方法の実行フローについて説明します。ここでは、WebLogic Serverで提供されるSAML 2.0サービスとWebLogicセキュリティ・サービス間の対話を示します。

- サービス・プロバイダ開始のシングル・サインオン

- IDプロバイダ開始のシングル・サインオン

サービス・プロバイダ開始のシングル・サインオン

一般的なサービス・プロバイダ開始のSSOシナリオでは、認証されていないユーザーがサービス・プロバイダ・サイトの保護されているリソースにアクセスしようとします。これに応じて、サービス・プロバイダは、適切なIDプロバイダ・パートナを識別し、そのパートナに認証リクエストをリダイレクトすることによってWeb SSOセッションを開始します。次に、IDプロバイダは通常、ログインWebアプリケーションを使用してユーザーを認証し、ユーザーID情報を含むSAMLアサーションを生成して、そのアサーションを認証レスポンスの形式でサービス・プロバイダに返します。

サービス・プロバイダは、認証レスポンスを受信すると、そのレスポンスに含まれているアサーションからID情報を抽出し、そのID情報をローカル・セキュリティ・レルムのサブジェクトにマッピングしてユーザーIDを検証します。ユーザーIDが正常にマッピングされると、サービス・プロバイダは保護されたリソースへのユーザーのアクセスを認可します。

図5-9に、一般的なサービス・プロバイダ開始のWebシングル・サインオン・セッションの実行フローを示します。

図5-9 サービス・プロバイダ開始のシングル・サインオン

実行フローを示す図5-9に記載されている番号の説明は以下のとおりです。

1. ユーザーがブラウザから、サービス・プロバイダによってホストされているWebLogicコンテナ上の保護されたリソースにアクセスしようとします。

2. WebLogicコンテナはWebLogicセキュリティ・サービスを呼び出し、ユーザーが認証されているかどうかを判別します。

3. ユーザーは認証されていないため、サービス・プロバイダは、認証されていないユーザーの情報を含む認証リクエストを生成し、IDプロバイダのシングル・サインオン・サービスのエンドポイントを使用して、IDプロバイダに送信します。
サービス・プロバイダは、認証リクエストの転送において次のバインディングのいずれかを使用するように構成できます。

- HTTP POST - HTTP POSTバインディングを使用すると、サービス・プロバイダは認証リクエストを含むHTTP POSTメッセージをユーザーのブラウザに送信します。その後、HTTP POSTメッセージはIDプロバイダのシングル・サインオン・サービスに送信されます。

- HTTPアーティファクト - サービス・プロバイダはSAMLアーティファクトを含むHTTPリダイレクト・メッセージをユーザーのブラウザに送信します。SAMLアーティファクトには、サービス・プロバイダのアーティファクト解決サービス(ARS)によって保持される認証リクエスト・メッセージへのポインタが含まれます。IDプロバイダはHTTPリダイレクト・メッセージを受信すると、サービス・プロバイダのARSにアーティファクト解決リクエストを送信して、認証リクエスト・メッセージを取得します。

- HTTPリダイレクト - サービス・プロバイダはHTTPリダイレクト・メッセージをユーザーのブラウザに送信します。ブラウザは、HTTP GETメッセージをIDプロバイダのシングル・サインオン・サービスに送信します。

4. ユーザーに対して、そのユーザーを認証可能なIDプロバイダによってホストされるログインWebアプリケーションが提供されます。IDプロバイダはユーザーに対しユーザーの資格証明のチャレンジを要求します。

5. ユーザーは、IDプロバイダにユーザー名とパスワードを送信し、認証処理を完了します。

6. IDプロバイダによってホストされるシングル・サインオン・サービスは、ユーザーのアサーションを生成し、サービス・プロバイダのアサーション・コンシューマ・サービス(ACS)に認証レスポンスを返します。

IDプロバイダは、次のバインディングを使用するように構成できます。

- HTTP POST - IDプロバイダはアサーションを含めた認証レスポンスをユーザーのブラウザに送信します。認証レスポンスは、HTTP POSTメッセージを使用してサービス・プロバイダに転送されます。

- HTTPアーティファクト - IDプロバイダはSAMLアーティファクトを含む認証レスポンスをユーザーのブラウザに送信します。SAMLアーティファクトには、IDプロバイダのアーティファクト解決サービス(ARS)によって処理されるアサーションへのポインタが含まれます。認証レスポンスは、HTTPリダイレクト・メッセージを使用してサービス・プロバイダに転送されます。サービス・プロバイダは、そのレスポンスを受信すると、アーティファクト解決リクエストをIDプロバイダのARSに送信してアサーションを取得します。
ACSはアサーションを検証し、そのアサーションからID情報を抽出して、ローカル・セキュリティ・レルムのサブジェクトにそのIDをマッピングします。

7. ACSはHTTPリダイレクト・メッセージをブラウザに送信し、セッションIDを含むCookieを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。
WebLogicセキュリティ・サービスは、認可チェックを実行して、リクエストされたリソースにブラウザがアクセス可能かどうかを判別します。認可チェックに成功すると、リソースへのアクセスが許可されます。

IDプロバイダ開始のシングル・サインオン

WebLogic Serverは、IDプロバイダによってWebシングル・サインオン・セッションが開始されるシナリオもサポートしています。このシナリオでは、ユーザーはIDプロバイダによって認証され、サービス・プロバイダによってホストされるリソースに対するリクエストを発行します。IDプロバイダは、サービス・プロバイダが要求していない認証レスポンスをサービス・プロバイダに送信することによってSSOセッションを開始します。

サービス・プロバイダは、認証レスポンスを受信すると、アサーションからユーザーIDを抽出し、そのIDをローカル・サブジェクトにマッピングして、リクエストされたリソースに対する認可チェックを実行します。認可チェックに成功すると、アクセスが許可されます。

図5-10に、一般的なIDプロバイダ開始のSSOセッションの実行フローを示します。

図5-10 IDプロバイダ開始のシングル・サインオン

実行フローを示す図5-10に記載されている番号の説明は以下のとおりです。

1. ユーザーに対して、そのユーザーを認証するIDプロバイダによってホストされるログインWebアプリケーションが提供されます。IDプロバイダはユーザーに対しユーザーの資格証明のチャレンジを要求します。

2. ユーザーは、IDプロバイダにユーザー名とパスワードを送信し、認証処理を完了します。
ユーザーは、サービス・プロバイダによってホストされるリソースに対するリクエストを発行します。

3. IDプロバイダによってホストされるシングル・サインオン・サービスは、サービス・プロバイダが要求していない認証レスポンスをサービス・プロバイダのアサーション・コンシューマ・サービス(ACS)に送信します。
IDプロバイダはSSOセッションの開始方法に関係なく、「サービス・プロバイダ開始のシングル・サインオン」で説明したのと同じバインディングを使用します。

4. ACSはアサーションを検証し、ID情報を抽出して、ローカル・セキュリティ・レルムのサブジェクトにそのIDをマッピングします。ACSはHTTPリダイレクト・メッセージをブラウザに送信し、セッションIDを含むCookieを渡して、リクエストされたリソースにブラウザがアクセスできるようにします。

5. WebLogicセキュリティ・サービスは、認可チェックを実行して、リクエストされたリソースにブラウザがアクセス可能かどうかを判別します。認可チェックに成功すると、リソースへのアクセスが許可されます。

デスクトップSSOのプロセス

このプロセスの仕組みは次のとおりです。

1. ネゴシエーションIDアサーション・プロバイダは、WWW-AuthenticateおよびAuthorization HTTPヘッダーをサポートするように構成されています。このネゴシエーションIDアサーション・プロバイダが、サーブレット認証フィルタを使用して、ネゴシエーション・プロトコルの認可されていないレスポンスに対して適切なWWW-Authenticateヘッダーを生成し、後続のリクエストでAuthorizationヘッダーを処理します。

2. ユーザーがWindows 2000または2003ドメインにログインします。このユーザーは、ドメインからKerberos資格証明を取得します。

3. ユーザーが、SPNEGOプロトコルをサポートするブラウザ(Internet Explorer、Mozillaなど)を使用して、アプリケーション・サーバーで実行されているWebアプリケーションにアクセスしようとします。アプリケーション・サーバーを実行するプラットフォームは、UNIXでもWindows 2000/2003でも構いません。

4. ブラウザが、アプリケーション・サーバーにGETリクエストを送信します。

5. アプリケーション・サーバーが、認可されていないレスポンスを適切なWWW-Authenticateヘッダーとともに送り返します。

6. サーブレット・コンテナが、サーブレット認証フィルタの構成済みチェーンをWebLogicセキュリティ・フレームワークから取得します。

7. サーブレット・コンテナが、サーブレット認証フィルタのチェーンを呼び出します。ネゴシエーション・サーブレット認証フィルタは、ネゴシエーション認証スキームのWWW-Authenticateリクエスト・ヘッダーを追加し、WebLogicセキュリティ・フレームワークに働きかけて初期ネゴシエーション・チャレンジを取得します。次のメッセージが送り返されます。
401 Unauthorize

WWW-Authenticate: Negotiate

8. ブラウザは、WWW-Authenticateヘッダーを受信し、ネゴシエート認証スキームをサポートできるかどうかを判別します。そして、サポートするGSSメカニズム・トークン・タイプを含むSPNEGOトークンを作成します。このトークンをBase64でエンコードし、元のGETメッセージのAuthorizationヘッダーを使用してアプリケーション・サーバーに返信します。次に例を示します。

GET...
Authorization: Negotiate <Base64 encoded SPNEGO token>

9. リクエストはまだ認可されていないため、サーブレット・コンテナがサーブレット認証フィルタを呼び出します。ネゴシエーション・サーブレット認証フィルタは、認可リクエスト・ヘッダーを処理してWebLogicセキュリティ・フレームワークを呼び出します。フレームワークは、トークンをネゴシエーションIDアサーション・プロバイダに渡します。

10. ネゴシエーションIDアサーション・プロバイダが、GSSコンテキストを使用して開始プリンシパルの名前を取得します。この名前はユーザー名にマップされ、コールバック・ハンドラによってWebLogicセキュリティ・フレームワークに返信されます。
WebLogicセキュリティ・フレームワークは、そのユーザーが所属するグループも判別します。

11. これで認証が完了し、GETリクエストが処理されます。

WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

WebLogic WebサービスとWebLogicセキュリティ・フレームワークは、SAML 1.1および2.0アサーションの生成、消費、および検証をサポートするように拡張されています。SAMLアサーションを使用する場合は、WebサービスがSAMLアサーションとそれに付随する証明データをWebLogicセキュリティ・フレームワークに渡します。SAMLアサーションが有効で信頼されれば、フレームワークが認証されたサブジェクトと信頼性のあるプリンシパルをWebサービスに返します。WebLogic WebサービスとWebLogicセキュリティ・フレームワークでは、次のSAMLアサーションがサポートされます。

- Sender-Vouches - サブジェクトとは異なるアサーション側がサブジェクトの検証を保証します。受信側がアサーション側との信頼関係を確立している必要があります。

- Holder-of-Key -「holder-of-key」サブジェクト確認が指定されたSAMLトークンは、リクエスト・メッセージの整合性を確保するために、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用できるようにすることを目的としたものです。
理論的には、アサーション側によってX.509のパブリック証明書(または他のキー情報)がSAMLアサーションに挿入されます。(厳密には、アサーション・パーティによりキーがサブジェクトにバインドされます。)この組み込まれた証明書を保護するには、SAMLアサーション自体がアサーティング・エンティティによって署名されている必要があります。WebLogic Serverの場合、SAMLアサーションはWebサービス・クライアントによって署名され、署名にはWebサービス・クライアントの秘密鍵が使用されます。つまり、アサーションの署名はSAML権限の署名であり、アサーションに含まれる証明書やアサーションにより特定される証明書に基づくものではありません。

- Bearer - アサーションのサブジェクトはアサーションのベアラーであり、アサーションの<SubjectConfirmationData>要素に含まれている属性を使用した確認に対するオプションの制約に従います。

以下の節では、これらのアサーションを処理する方法について説明します。

Sender-Vouchesアサーション

すべてのSender-Vouchesアサーションは基本的に同じで、信頼の確立方法(トランスポートにSSLを使用するかどうか、SAMLアサーションとメッセージ本文が署名されるかどうか)だけが異なります。

Sender-Vouchesアサーションは、次の方法で使用します。

1. ユーザーがWebLogic Webサービスを呼び出します。

2. WebサービスがユーザーからのSAMLアサーションをリクエストします。

3. ユーザーがSAMLアサーションを生成してWebサービスに返します。

4. Webサービスが、適切なSAMLアサーションを生成するSAML資格証明マッピング・プロバイダを呼び出します。

5. 次のいずれかが発生します。なお、以下に示すのはもっとも起こりやすい状況であり、これ以外の状況にもなり得ることに留意してください。

- Webサービスが、SOAPメッセージ内の非SSLトランスポートを使用して、署名されていないアサーションを宛先に送信します。このタイプのアサーションでは、証明データがSOAPメッセージに含まれていないため、アサーションは信頼できず、アサーションが信頼性のあるパーティから送られたと見なすこともできません。

- Webサービスが、SSLプロトコルを使用して、SOAPメッセージ内の署名されていないアサーションを宛先に送信します。このタイプのアサーションでは、クライアント証明書を使用して信頼を確立します。

- Webサービスがアサーションに署名し、SOAPメッセージ内の非SSLトランスポートを使用して宛先に送信します。このタイプのアサーションでは、署名が信頼のための証明データを提供しますが、接続が失われていないと見なすことはできません。一方、署名されたアサーションの変更については検出できます。これは、どのような変更があっても署名の信頼性が失われるためです。

- Webサービスがアサーションに署名し、SSLプロトコルを使用してSOAPメッセージ内の署名されたアサーションを宛先に送信します。このタイプのアサーションでは、署名またはクライアント証明書によって信頼が確立されます。

6. SAML IDアサーション・プロバイダでアサーションが消費されて検証され、アサーションを信頼するかどうかが決定されます。

7. アサーションが信頼されると、SAML IDアサーション・プロバイダがユーザー・プリンシパルと(可能であれば)グループ・プリンシパルを含むサブジェクトを作成し、そのサブジェクトをWebサービスに返します。

8. Webサービスがユーザーにレスポンスを返します。

Holder-of-Keyアサーション

Holder-of-Keyアサーションでは、ユーザーを信頼するかどうかを確認する上で、Webサービス・クライアントがWebサービス・サーバーに依存します。

Holder-of-Keyアサーションは、次の方法で使用します。

1. ユーザーが、未確認のメカニズムでWebサービス・クライアントの認証を受けます。Webサービス・クライアントはローカルでもリモートでもよく、WebLogicサーバー・インスタンスでなくても構いません。

2. Webサービス・クライアントがユーザーを信頼し、ユーザーの証明書を含むSAMLアサーションを生成して、その秘密鍵でSAMLアサーションに署名します。Webサービス・クライアントが、SAMLアサーションをユーザーに返します。

3. ユーザーが、SAMLアサーション情報をSOAPメッセージのwsse:Securityヘッダーに挿入します。メッセージ本文は、ユーザーの秘密鍵で署名されます。

4. ユーザーがWebLogic Webサービスを呼び出します。

5. Webサービスが、SOAPメッセージをWebサービス・サーバー(この場合はWebLogic Serverインスタンス)に送信します。Webサービス・サーバーは、SAMLアサーションとSOAPメッセージを信頼するかどうかに基づいて信頼の決定を下します。

6. Webサービス・サーバーでアサーションが受信され、アサーションはSAML IDアサーション・プロバイダに渡されます。SAML IDアサーション・プロバイダでは、アサーションの署名とそれに使用されている証明書の信頼性を検証します。
これが成功すると、Webサービス・サーバーではholder-of-keyアサーションのキーが実際にそのアサーションのサブジェクトに属していると見なせます。その結果、Webサービスでそのキーを使用して、SOAPメッセージの署名を検証できるようになります。これによって、SOAPメッセージがキーの保持者により生成され、送信されたことが認められます。X.509証明書自体の信頼性の検証はWebサービス・サーバーに任されます。

Webサービス・サーバーによって、SAMLアサーション用のプリンシパルを含むサブジェクトがWebサービス・クライアントに返されます。

7. Webサービス・クライアントがユーザーにレスポンスを返します。

このアサーションでは、必要に応じてSSLプロトコルを使用できます。SSLプロトコルを使用する場合は、クライアント証明書も証明データとして使用できます。

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

WebLogic Serverのこのリリースでのセキュリティは、一連のセキュリティ・サービス・プロバイダ・インタフェース(SSPI)に基づいています。開発者およびサード・パーティ・ベンダーは、SSPIを使用してWebLogic Server環境向けのセキュリティ・プロバイダを開発できます。SSPIは、認証、IDアサーション、認可、監査、裁決、ロール・マッピング、資格証明マッピング、および証明書の検索と検証に利用可能です。

SSPIを使用すると、カスタム・セキュリティ・プロバイダでWebLogic Serverリソースを保護することができます。SSPIを使用してカスタム・セキュリティ・プロバイダを開発することも、サード・パーティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することもできます。

カスタム・セキュリティ・プロバイダの開発に役立つカスタム・セキュリティ・プロバイダのサンプルもOracle Technology Network (OTN)から入手できます。

カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

WebLogicセキュリティ・プロバイダ

この節では、お使いのWebLogic Server製品に付属しているセキュリティ・プロバイダについて説明します。セキュリティ・プロバイダは、WebLogic Serverのセキュリティ・レルムに「プラグイン」してアプリケーションにセキュリティ・サービスを提供するためのモジュールです。セキュリティ・プロバイダは、アプリケーションのかわりにWebLogicセキュリティ・フレームワークに働きかけを行います。

WebLogic Server製品に付属しているセキュリティ・プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム・セキュリティ・プロバイダで補足するか、あるいはカスタム・セキュリティ・プロバイダに置き換えることができます。カスタム・セキュリティ・プロバイダは以下のようにして開発します。

- weblogic.security.spiパッケージから適切なセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してセキュリティ・プロバイダの実行時クラスを作成します。

- MBean定義ファイル(MDF)を作成し、WebLogic MBeanMakerユーティリティを使用してMBeanタイプを生成します。MBeanタイプは、セキュリティ・プロバイダの構成と管理に使用します。

詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

図5-11に、WebLogicセキュリティ・レルムにおいて必須および省略可能なセキュリティ・プロバイダを示します。

図5-11 WebLogicセキュリティ・プロバイダ

以下の節では、セキュリティ・プロバイダについて説明します。

- WebLogic認証プロバイダ

- その他の認証プロバイダ

- パスワード検証プロバイダ

- WebLogic IDアサーション・プロバイダ

- SAML 1.1用のSAML IDアサーション・プロバイダ

- ネゴシエーションIDアサーション・プロバイダ

- WebLogicプリンシパル検証プロバイダ

- WebLogic認可プロバイダ

- WebLogic裁決プロバイダ

- WebLogicロール・マッピング・プロバイダ

- WebLogic監査プロバイダ

- WebLogic資格証明マッピング・プロバイダ

- SAML 1.1用のSAML資格証明マッピング・プロバイダ

- SAML 2.0資格証明マッピング・プロバイダ

- PKI資格証明マッピング・プロバイダ

- WebLogic証明書パス・プロバイダ

- 証明書レジストリ

- バージョン管理可能なアプリケーションのプロバイダ

WebLogic認証プロバイダ

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic認証プロバイダが含まれています。WebLogic認証プロバイダは、ユーザー名とパスワードの委託認証とWebLogic Serverセキュリティのダイジェスト認証をサポートします。ユーザーとグループの情報の格納には、組込みLDAPサーバーを利用します。このプロバイダを使用すると、ユーザーとグループ・メンバーシップを編集、表示、および管理できます。

このプロバイダでは、ユーザーに割り当てることができる一連の属性(従業員番号、部署番号など)も提供されます。

その他の認証プロバイダ

WebLogic Serverでは、デフォルトのセキュリティ・レルムにおいて、以下の認証プロバイダをWebLogic認証プロバイダのかわりとして使用したり、WebLogic認証プロバイダと併用したりできます。

- 外部LDAPストア(Open LDAP、iPlanet、Microsoft Active Directory、Oracle Internet Directory、Oracle Virtual Directory、Novell NDS)にアクセスする一連のLDAP認証プロバイダ。

- 認証を行うために、データベースに格納されているユーザー、パスワード、グループ、およびグループ・メンバーシップ情報にアクセスする一連のデータベース管理システム(DBMS)プロバイダ。必要に応じて、WebLogic Serverを使用してユーザー、パスワード、グループ、およびグループ・メンバーシップ情報を管理できます。DBMS認証プロバイダは、RDBMSセキュリティ・レルムからのアップグレード・パスです。
以下のDBMS認証プロバイダを使用できます。

- SQL認証プロバイダ - ユーザー、パスワード、グループ、およびグループ・メンバーシップ情報の表示や編集をサポートする管理可能な認証プロバイダ。

- 読取り専用SQL認証プロバイダ - WebLogic Server管理コンソールを使用したデータベース内のユーザーの認証およびデータベースのコンテンツの表示をサポートする認証プロバイダ。この認証プロバイダは特定のSQL文のセットを必要とするため、すべてのニーズには対応できない可能性があります。

- カスタムDBMS認証プロバイダ - 認証をサポートするだけの実行時認証プロバイダ。このプロバイダでは、データベースに問い合わせて認証情報を取得するためのコードをユーザーが記述する必要があります。DBMS認証プロバイダを特殊なデータベース・ニーズに適合させるための柔軟な認証プロバイダです。

- 認証を行うためにWindows NTユーザーおよびグループを使用するWindows NT認証プロバイダ。Windows NT認証プロバイダは、Window NTセキュリティ・レルムのアップグレード・パスです。WebLogic Server管理コンソールでは、Windows NTのユーザーおよびグループを表示することはできますが、管理することはできません。

- X509証明書に関連付けられたユーザーのLDAPオブジェクトをルックアップし、LDAPオブジェクトの証明書が提示された証明書と一致することを確認し、認証を目的としてLDAPオブジェクトからユーザーの名前を取得するLDAP X509 IDアサーション・プロバイダ。

注意:
デフォルトでは、これらの認証プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。

パスワード検証プロバイダ

WebLogic Serverには、パスワード検証プロバイダが付属しており、このプロバイダが次に示す1つ以上の認証プロバイダで構成されていると、パスワード構成ルール・セットを管理および適用することができます。

- WebLogic認証プロバイダ

- SQL認証プロバイダ

- LDAP認証プロバイダ

- Active Directory認証プロバイダ

- iPlanet認証プロバイダ

- Novell認証プロバイダ

- Open LDAP認証プロバイダ

認証プロバイダでパスワード検証プロバイダが構成されている場合、認証プロバイダは、パスワードが作成または更新されると、パスワード検証プロバイダを呼び出します。呼び出されたパスワード検証プロバイダは、そのパスワードが構成可能な構成ルール・セットに基づく条件を満たすかどうかを検証します。

WebLogic IDアサーション・プロバイダ

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がトークンとして使用される場合に使用します。

- WSSE_PASSWORD_DIGEST - パスワード・タイプwsse:PasswordDigestのwsse:UsernameTokenがトークンとして使用される場合に使用します。

SAML 1.1用のSAML IDアサーション・プロバイダ

SAML IDアサーション・プロバイダV2は、SAML 1.1アサーションを検証し、発行者が信頼されていることを確認します。信頼されていれば、アサーションに含まれる認証文に基づき、IDがアサートされます。

プロバイダの構成には、SAMLソース・サイトおよび宛先サイトのSSOサービス(ITS、ACS、ARSなど)を構成してサーバーで実行できるようにするための設定が含まれています。

SAML IDアサーション・プロバイダでは、以下のSAMLサブジェクト確認メソッドがサポートされています。

- artifact

- bearer

- sender-vouches

- holder-of-key

SAML 2.0 IDアサーション・プロバイダ

SAML 2.0 IDアサーション・プロバイダは、SAML 1.1用のSAML IDアサーション・プロバイダV2と同様に、SAML 2.0アサーションを検証し、発行者が信頼されていることを確認します。信頼されていれば、アサーションに含まれる認証文に基づき、IDがアサートされます。

プロバイダの構成には、SAML 2.0サービス・プロバイダ・サービス(アサーション・コンシューマ・サービスやアーティファクト解決サービスなど)を構成してサーバーで実行できるようにするための設定が含まれています。

SAML 2.0 IDアサーション・プロバイダでは、以下のSAMLサブジェクト確認メソッドがサポートされています。

- bearer

- sender-vouches

- holder-of-key

ネゴシエーションIDアサーション・プロバイダ

ネゴシエーションIDアサーション・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでのSSOに使用します。具体的には、SPNEGOトークンをデコードしてKerberosトークンを入手し、このKerberosトークンを検証してWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。Java GSS APIの詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-features.htmlを参照してください。

ネゴシエーションIDアサーション・プロバイダは、WebLogicサーブレット・コンテナと対話します。このコンテナが、WWW-AuthenticateヘッダーおよびWWW-Authorizationヘッダーを処理して、適切なNegotiateヘッダーを追加します。

デフォルトでは、ネゴシエーションIDアサーション・プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。ネゴシエーションIDアサーション・プロバイダは、WebLogic IDアサーション・プロバイダのかわりとして使用したり、WebLogic IDアサーション・プロバイダと併用したりできます。

WebLogicプリンシパル検証プロバイダ

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の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のPrincipalValidator SSPIの実装に関する項を参照してください。

IDアサーション・プロバイダが特定のタイプのトークンをサポートするのと同じように、プリンシパル検証プロバイダは特定のタイプのプリンシパルに対する署名と信頼性の確認を行います。そのため、WebLogicプリンシパル検証プロバイダを使用して、WebLogic ServerユーザーまたはWebLogic Serverグループを表すプリンシパルに対して署名と検証を行うことができます。

WebLogic認可プロバイダ

バージョン9.1からのWebLogic Serverには、OASISのeXtensible Access Control Markup Language (XACML) 2.0標準をサポートする認可プロバイダが付属しています。このWebLogicプロバイダでは、標準XACML 2.0のあらゆる関数、属性、およびスキーマ要素で表されるポリシーのインポート、エクスポート、永続化、および実行が可能です。

WebLogic Server 9.1以降で新しく作成されたドメインでは、デフォルトでXACML認可プロバイダが使用されるようになっています。既存のドメインをWebLogic Server 9.1以降のリリースにアップグレードした場合、サード・パーティ製パートナ・プロバイダやオリジナルのWebLogic Server専用プロバイダなどの、現行で指定されている認可プロバイダが引続き使用されます。WebLogic Server管理コンソールを使用して認可プロバイダを新しく追加する場合、新しいプロバイダをDefaultAuthorizerプロバイダまたはXACMLプロバイダとして追加できます。

カスタムXACMLプロバイダはこのリリースではサポートされていません。

また、WebLogic Serverバージョン9.1には「デフォルト」のWebLogic認可プロバイダも用意されています。このプロバイダによって、9.1より前のバージョンのWebLogic Serverに対するデフォルトの認可が適用されています。ポリシー・ベースの認可エンジンを使用して、WebLogic認可プロバイダからアクセス決定が返され、特定のユーザーが保護対象のWebLogicリソースへのアクセスを許可されているかどうかが判断されます。また、WebLogic認可プロバイダは、システム内のセキュリティ・ポリシーのデプロイメントとアンデプロイメントもサポートしています。

WebLogic裁決プロバイダ

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic裁決プロバイダが含まれています。このプロバイダは通常、複数の認可プロバイダのアクセス決定から異なる結果が返された場合に裁決を行い、WebLogicリソースへのアクセスを許可するかどうかを最終的に判定します。ただし、デフォルトのセキュリティ・レルムには認可プロバイダが1つしかなく、生成されるアクセス決定は1つのみなので、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裁決プロバイダを構成するときに設定します。裁決プロバイダの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のWebLogic裁決プロバイダの構成に関する項を参照してください

WebLogicロール・マッピング・プロバイダ

バージョン9.1からのWebLogic Serverには、OASISのeXtensible Access Control Markup Language (XACML) 2.0標準をサポートするロール・マッピング・プロバイダが付属しています。このWebLogicプロバイダでは、標準XACML 2.0のあらゆる関数、属性、およびスキーマ要素で表されるポリシーのインポート、エクスポート、永続化、および実行が可能です。

WebLogic Server 9.1以降で新しく作成されたドメインでは、デフォルトでXACMLロール・マッピング・プロバイダが使用されるようになっています。既存のドメインをWebLogic Server 9.1以降のリリースにアップグレードした場合、サード・パーティ製パートナ・プロバイダやオリジナルのWebLogic Server専用プロバイダなどの、現行で指定されているロール・マッピング・プロバイダが引続き使用されます。WebLogic Server管理コンソールを使用してロール・マッピング・プロバイダを新しく追加する場合、新しいプロバイダをDefaultRoleMapperプロバイダまたはXACMLプロバイダとして追加できます。

カスタムXACMLプロバイダはこのリリースではサポートされていません。

また、WebLogic Serverバージョン9.1には「デフォルト」のWebLogicロール・マッピング・プロバイダも用意されています。このプロバイダによって、9.1より前のバージョンのWebLogic Serverに対するデフォルトのロール・マッピングが適用されています。このプロバイダは、デフォルト・ユーザーとWebLogicリソースのそれぞれについて、保護されている特定のWebLogicリソースに関する特定のユーザー(サブジェクト)の動的ロールを決定します。また、WebLogicロール・マッピング・プロバイダは、システム内のロールのデプロイメントとアンデプロイメントをサポートしています。WebLogicロール・マッピング・プロバイダは、WebLogic認可プロバイダと同じセキュリティ・ポリシー・エンジンを使用します。

WebLogic監査プロバイダ

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic監査プロバイダが含まれています。このプロバイダは、WebLogicセキュリティ・フレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。

WebLogic資格証明マッピング・プロバイダ

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムにはWebLogic資格証明マッピング・プロバイダが含まれています。WebLogic資格証明マッピング・プロバイダを使用して、WebLogic Serverユーザーを、エンタープライズ情報システム(EIS) (たとえば、Oracle、SQL Serverなどのリレーショナル・データベース)にアクセスするためにリソース・アダプタで使用すべき適切な資格証明に関連付ける(つまりマップする)ことができます。プロバイダは、ユーザーの認証資格証明(ユーザー名とパスワード)をレガシー・アプリケーションで必要になる認証資格証明にマップするので、レガシー・アプリケーションは必要な資格証明情報を取得できます。たとえば、EISはメインフレーム・トランザクション処理システムでも、データベース・システムでも、Javaプログラミング言語で記述されていないレガシー・アプリケーションでもかまいません。

WebLogic Serverのユーザーおよびグループと他のシステムのユーザー名/パスワードとの間のマッピングであれば、WebLogic資格証明マッピング・プロバイダで十分です。

SAML 1.1用のSAML資格証明マッピング・プロバイダ

SAML資格証明マッピング・プロバイダV2では、依存側または宛先サイトの構成に基づく認証されたサブジェクトに対するSAML 1.1アサーションを生成します。アサーションには認証文と、必要に応じてWebLogic Serverのグループ情報を含む属性文が含まれます。リクエストされたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合) AttributeStatement内に置かれます。

WebLogic Server管理コンソールの「フェデレーション・サービス」構成ページに、SAMLのソース・サイトおよび宛先サイトのSSOサービス(ITS、ACS、ARSなど)を構成し、サーバーで実行するために有効化する設定があります。

SAML資格マッピング・プロバイダは、以下のSAMLサブジェクト確認メソッドをサポートしています。

- artifact

- bearer

- sender-vouches

- holder-of-key

SAML 2.0資格証明マッピング・プロバイダ

SAML 2.0資格証明マッピング・プロバイダは、IDプロバイダ・サービスとサービス・プロバイダ・パートナの構成に基づく認証されたサブジェクトに対するSAML 2.0アサーションを生成します。アサーションには認証文と、必要に応じてWebLogic Serverのグループ情報を含む属性文が含まれます。リクエストされたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合) AttributeStatement内に置かれます。

WebLogic Server管理コンソールのSAML 2.0用の「フェデレーション・サービス」構成ページに、SAML 2.0のソース・サイトおよび宛先サイトのサービス(シングル・サインオン、アーティファクト解決サービスなど)を構成し、サーバーで実行するために有効化する設定があります。

SAML資格マッピング・プロバイダは、以下のSAMLサブジェクト確認メソッドをサポートしています。

- bearer

- sender-vouches

- holder-of-key

PKI資格証明マッピング・プロバイダ

PKI (公開鍵インフラストラクチャ)資格証明マッピング・プロバイダは、WebLogic Serverのサブジェクト(開始者)とターゲット・リソース(および必要であれば資格証明アクション)を、ターゲット・リソースを使用する際にアプリケーションで使用する公開鍵と秘密鍵のペアまたは公開証明書にマップします。このプロバイダを使用して、公開鍵と秘密鍵のペアまたは公開証明書に別名をマップすることもできます。PKI資格証明マッピング・プロバイダは、サブジェクトとリソース名(または別名)を使用して対応する資格証明をキーストアから検索します。

WebLogic証明書パス・プロバイダ

WebLogic証明書パス・プロバイダは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。証明書パス・プロバイダは、証明書のパスを完了させ、特定のサーバー・インスタンスのために構成された信頼性のあるCAを使用して証明書を検証します。完了できない証明書チェーンは無効になります。

また、WebLogic証明書パス・プロバイダは、チェーン内の署名をチェックして、チェーンが期限切れでないことを確認し、チェーン内のいずれかの証明書が、サーバー用に構成された信頼性のあるCAによって発行されたものであることを確認します。いずれかのチェックが失敗した場合、そのチェーンは有効ではありません。

最後に、プロバイダは、各証明書の基本的な制約(証明書が他の証明書を発行できるかどうか)をチェックし、証明書がチェーン内の適切な場所にあることを確認します。

WebLogic証明書パス・プロバイダは、セキュリティ・レルム内の証明書パス・ビルダーまたは証明書パス検証プロバイダとして使用できます。

証明書レジストリ

証明書レジストリを使用すると、システム管理者はサーバーへのアクセスが許可されている信頼性のあるCA証明書のリストを明示的に構成できます。証明書レジストリは、失効チェックを実行するための、費用のかからないメカニズムを提供します。管理者は、証明書レジストリから削除することによって、証明書を無効にします。このレジストリは、組込みLDAPサーバーに格納されます。

証明書レジストリは、サーバー単位ではなくドメイン単位で構成します。

証明書レジストリは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。どちらの場合でも、証明書レジストリは、チェーンの目的の証明書がレジストリに格納されていることを検証します。

バージョン管理可能なアプリケーションのプロバイダ

バージョン管理可能なアプリケーションは、アプリケーション・アーカイブ(EARファイル)のマニフェスト内で指定されているアプリケーション・アーカイブのバージョンを持つアプリケーションです。バージョン管理可能なアプリケーションはside-by-sideでデプロイでき、同時にアクティブにすることが可能です。バージョン管理可能なアプリケーションを使用すると、アプリケーションの複数のバージョンを利用できます。各バージョンには、個別のセキュリティ制約を設定できます。

バージョン管理可能なアプリケーションのプロバイダSSPIを使用すると、バージョンが作成および削除されたときに、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。また、バージョンが1つしかないアプリケーションが削除された場合にも、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。

用語集

アクセス制御リスト(ACL)

WebLogic 6.xで、コンピュータ・リソースに対するアクセスの制御に使用されるデータ構造。アクセス制御リスト(ACL)の各エントリには、個々のユーザーやユーザーのグループを表す特定のプリンシパルに関連付けられた一連の権限が含まれます。エントリは、肯定的なものでも否定的なものでもかまいません。権限を付与するエントリが肯定的となり、権限を拒否するエントリが否定的となります。WebLogic Server 7.0以降では、ACLは非推奨になり、かわりにセキュリティ・ポリシーが使用されます。WebLogic Server 12.2.1では、ACLのサポートは削除されました。

アクセス決定

サブジェクトがWebLogicリソースに対して特定の操作を実行する権限を持っているかどうかを判定するコード。アクセス決定の結果は、許可、拒否、または決定の放棄のいずれかです。アクセス決定は、認可プロバイダのコンポーネントです。「認可プロバイダ」、「サブジェクト」、「WebLogicリソース」も参照してください。

ACL

「アクセス制御リスト(ACL)」を参照してください。

裁決プロバイダと裁決

複数のアクセス決定から返される結果を調停し、アクセス決定間の競合を解決して、PERMITまたはDENYの最終判定を行うWebLogicセキュリティ・プロバイダ。裁決は裁決プロバイダのコンポーネントです。「アクセス決定」、「セキュリティ・プロバイダ」も参照してください。

アーティファクト解決サービス(ARS)

SAMLアーティファクトの内容を格納し、IDプロバイダまたはサービス・プロバイダから送信されるアーティファクト解決リクエストに応答するアドレス可能なSAMLサービス。

アサーティング・パーティ

Web SSOの使用時に、特定のユーザーが認証済で、関連する属性が付与されていることをアサートする側。例: Dan Murphyというユーザーがいて、dmurphy@company.comという電子メール・アドレスを持っており、パスワード・メカニズムによってこのドメインに認証されました。Web SSOでは、アサーティング・パーティはSAML権限とも呼ばれます。「リライイング・パーティ」、「Security Assertion Markup Language (SAML)」、「シングル・サインオン」も参照してください。

アサーション

ユーザーがドメインにログインしているかどうかに関するXML文。ユーザー名とグループを含むサブジェクトのXML表現と考えることができます。

アサーション・コンシューマ・サービス(ACS)

SAMLパートナによって生成されたアサーションやアーティファクトを受け取り、これらを使用してサービス・プロバイダ(宛先サイト)でユーザーを認証するアドレス可能なコンポーネント。

アサーション検索サービス(ARS)

アーティファクトをSAML 1.1アサーションに変換する、SAML 1.1アーキテクチャのアドレス可能なコンポーネント。

非対称鍵暗号方式

データの暗号化と復号化に異なる鍵(秘密鍵と公開鍵)を使用する暗号化アルゴリズムを用いる暗号方式。公開鍵で暗号化されたデータは、秘密鍵を使用することによってのみ復号化できます。この非対称性によって、公開鍵暗号方式は幅広く使用されています。公開鍵暗号方式とは、非対称鍵暗号方式の別の呼び名です。「秘密鍵」、「公開鍵」、「対称鍵暗号方式」も参照してください。

監査

否認防止を目的として、処理リクエストとその結果に関する情報を収集、格納および配布するプロセス。監査は、コンピュータのアクティビティの電子的な記録を提供します。「監査プロバイダ」も参照してください。

監査プロバイダ

監査サービスを提供するセキュリティ・プロバイダ。「監査」、「セキュリティ・プロバイダ」も参照してください。

認証

ユーザーまたはシステム・プロセスのIDを検証するためのプロセス。認証にはまた、必要に応じて、身元情報を記憶したり、トランスポートしたり、様々なシステム・コンポーネントの利用に供する働きもあります。通常、認証はユーザー名とパスワードの組合せを使用して行われますが、トークンを使用することもできます。「認証プロバイダ」、「IDアサーション」、「LoginModule」、「境界認証」、「トークン」、「ユーザー」も参照してください。

認証プロバイダ

ユーザーを検証することで、WebLogic Serverが信頼を確立することを可能にするセキュリティ・プロバイダ。WebLogicセキュリティ・サービス・アーキテクチャは、ユーザー名とパスワードの認証、証明書に基づく認証(WebLogic Serverを直接使用する)、およびHTTP証明書に基づく認証(外部のWebサーバーを介して行う)を実行する認証プロバイダをサポートします。「認証」、「デジタル証明書」、「セキュリティ・プロバイダ」、「ユーザー」も参照してください。

認可

ユーザーのセキュリティ・ロールと要求されたWebLogicリソースのセキュリティ・ポリシーに基づいてWebLogicリソースに対するユーザーのアクセスを許可または拒否するプロセス。「認可プロバイダ」、「セキュリティ・ポリシー」、「ユーザー」、「WebLogicリソース」も参照してください。

認可プロバイダ

ユーザーのセキュリティ・ロールと要求されたWebLogicリソースのセキュリティ・ポリシーに基づいてWebLogicリソースへのアクセスを制御するセキュリティ・プロバイダ。「セキュリティ・プロバイダ」、「ユーザー」、「WebLogicリソース」も参照してください。

証明書

「デジタル証明書」を参照してください。

証明書認証

デジタル証明書を使用することにより、サーバーがクライアントのIDを信頼するためのメソッド。証明書認証は、ユーザーが知っていること(秘密鍵を保護するパスワード)に加えてユーザーが持っているもの(秘密鍵を保護するパスワード)に基づいて行われるため、一般的にパスワード認証よりもよく使用されます。

認証局

公開鍵証明書を発行する、信頼性のあるエンティティ。認証局は、公証人と同じようにユーザーの現実世界の身元を証明します。「証明書チェーン」、「デジタル証明書」、「エンティティ」、「秘密鍵」、「公開鍵」、「信頼性のある(ルート)認証局」も参照してください。

証明書チェーン

信頼性のある認証局の秘密鍵、それに対応する公開鍵、およびデジタル証明書のチェーンを含む配列。各認証局は前のデジタル証明書の発行元です。サーバーの証明書、権限、権限2、権限3でチェーンが構成されている場合、サーバーの証明書は権限によって署名され、権限の証明書は権限2によって署名され、権限2の証明書は権限3によって署名されています。これらの権限のいずれかの認証局がクライアントによって認識されると、クライアントはサーバーを認証します。「信頼性のある(ルート)認証局」も参照してください。

証明書検索および検証(CLV)フレームワーク

証明書のパスを完了させ、X509証明書チェーンを検証するWebLogic Serverフレームワーク。CLVフレームワークは、証明書または証明書チェーンを受け取り、チェーンを完成させ(必要な場合)、チェーン内の証明書を検証します。

証明書への参照

証明書チェーンを一意に識別する文字列。たとえば、サブジェクトDNや、発行者DNにシリアル番号を付加したものを使用します。

証明書レジストリ

ドメイン内のサーバーにアクセス可能な信頼性のあるCA証明書のリスト。証明書レジストリは、失効チェックのためのメカニズムを提供します。証明書レジストリにある証明書のみが有効となります。

証明書失効リスト(CRL)の実装

信頼性のあるCAによって取り消された証明書のリスト。

証明書パス

メモリー内に証明書チェーンを格納するJDKクラス。証明書チェーンを検索および検証するためのJDKアーキテクチャおよびフレームワークを指す場合にも使われます。

証明書パス・ビルダー

証明書検索および検証(CLV)フレームワークのプロバイダ。必要に応じて証明書パスを完了させ、証明書を検証します。

証明書パス・バリデータ

CLVフレームワークのプロバイダ。証明書チェーン内の証明書を検証します。

接続フィルタ

サーバーがネットワーク・クライアントからの着信接続を許可するかどうかを判定するためにWebLogic Serverが使用するプログラミング可能なフィルタ。ユーザーの特性に基づいてWebLogicリソースを保護するセキュリティ・ポリシーに加えて、ネットワーク接続に基づいてフィルタ処理を行うことでセキュリティの層を追加できます。「セキュリティ・ポリシー」、「ユーザー」、「WebLogicリソース」も参照してください。

コネクタ

「リソース・アダプタ」を参照してください。

コンテキスト・ハンドラ

ContextHandlerは、リソース・コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール・マッピング決定を行うセキュリティ・プロバイダに渡す高性能なWebLogicクラスです。ContextHandlerインタフェースを使用すると、内部WebLogicリソース・コンテナでWebLogicセキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandlerは本質的には名前と値のリストなので、セキュリティ・プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandlerの使用には、WebLogicリソース・コンテナとセキュリティ・プロバイダの間の緊密な連携が不可欠です。「セキュリティ・プロバイダ」、「WebLogicコンテナ」、「WebLogicセキュリティ・フレームワーク」も参照してください。

資格証明

新しいサービスにアクセスするサブジェクトを認証するための情報が格納される、サブジェクトのセキュリティ関連の属性。資格証明のタイプには、ユーザー名とパスワードの組合せ、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/spec/CORBA/を参照してください。

カスタム・セキュリティ・プロバイダ

サード・パーティ・セキュリティ・ベンダーまたはセキュリティ開発者によって作成されるセキュリティ・プロバイダ。WebLogicセキュリティ・サービスへの統合が可能です。カスタム・セキュリティ・プロバイダは、Security Service Provider Interface (SSPI)の実装です。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サーバーをセキュリティ・プロバイダ・データベースとして使用します。「資格証明」、「グループ」、「セキュリティ・ポリシー」、「セキュリティ・ロール」も参照してください。

目的の証明書

証明書チェーン内で最後の証明書と見なされる証明書。

エンティティ

特定の個別の単位として独立した存在。エンティティの例には、人、企業、オブジェクトなどがあります。

フィルタ

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認証局」または「アサーティング・パーティ」も参照してください。

サイト間転送サービス(ITS)

SAML 1.1処理のための機能のポイント(アーティファクト、リダイレクト生成など)を提供する、SAML 1.1アーキテクチャのアドレス可能なコンポーネント。

JAAS制御フラグ

セキュリティ・レルムに複数の認証プロバイダが構成されている場合に、ログイン・シーケンスによる認証プロバイダの使用方法を決定するフラグ。「認証プロバイダ」も参照してください。

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://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.htmlを参照してください。「Java Cryptography Extensions (JCE)」も参照してください。

Java Cryptography Extensions (JCE)

暗号化、鍵交換、およびMessage Authentication Code (MAC)アルゴリズムのためのAPIを含めてJava Cryptography Architecture APIを拡張するJavaパッケージ・セット。(JCEはJCAの一部として考えることができます。)JCEの詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.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セキュリティ・マネージャ」、「ポリシー条件」も参照してください。

JNDI

「Java Naming and Directory Interface (JNDI)」を参照してください。

KDC/TGS

キー配布センター/チケット認可サービス。Kerberos認証では、KDCがユーザー・プリンシパルのリストを保持します。KDCには、ユーザーの初期チケットのkinitプログラムを介してアクセスします。チケット認可サービスはサービス・プリンシパルのリストを保持しており、ユーザーがこのようなサービスを提供するサーバーの認証を受ける必要があるときに、接続されます。

KDC/TGSは信頼性のあるサード・パーティで、セキュアなホスト上で実行する必要があります。それは、チケット認可チケットとサービス・チケットを作成します。通常、KDCとTGSは同じエンティティです。

Kerberos

マサチューセッツ工科大学のAthenaプロジェクトにおいて開発されたネットワーク認証サービス。分散環境でのセキュリティが強化されています。Kerberosは、共有秘密に依存してサード・パーティがセキュアであると見なす、信頼性のあるサード・パーティ認証システムです。ユーザーにシングル・サインオン機能とデータベース・リンク認証(MIT Kerberosのみ)を提供します。パスワード・ストレージを一元化し、PCのセキュリティを拡張できます。

Kerberosチケット

物理的にセキュアでないネットワークに対するアクセスの制御に使用される数百バイトの長さのシーケンス。KerberosチケットはKerberosプロトコルに基づいています。Kerberosはネットワーク認証プロトコルであり、このプロトコルを使用することで、ネットワークを越えて通信を行うエンティティ(ユーザーおよびサービス)は盗聴、反復などの攻撃を防ぎながら相互に身元を証明できます。このプロトコルは、秘密鍵暗号方式を使用してクライアント/サーバー・アプリケーションに強力な認証を提供するために設計されました。詳細は、http://web.mit.edu/kerberos/www/を参照してください。「秘密鍵」も参照してください。

キーストア

秘密鍵と信頼性のある認証局の組合せのメモリー内集合。情報は、パスワード、クレジット・カード番号、暗証番号などの個人を識別する情報のパスフレーズによって保護されます。WebLogic Server管理コンソールでは、キーストアは信頼性のあるキーストアと呼ばれます。詳細は、Javadoc (http://docs.oracle.com/javase/8/docs/api/index.html)を参照してください。「秘密鍵」、「信頼性のある(ルート)認証局」も参照してください。

LDAP認証プロバイダ

Lightweight Data Access Protocol (LDAP)サーバー(iPlanet、Active Directory、Novell、OpenLDAPなど)を使用してユーザーおよびグループ情報にアクセスする認証プロバイダ。「グループ」、「ユーザー」も参照してください。

LoginModule

「JAAS LoginModule」を参照してください。

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認証」、「信頼性のある(ルート)認証局」も参照してください。

nonce

ダイジェスト認証で使用する不透明なトークン。

否認防止

セキュリティ・イベントが発生したという決定的な証拠。

一方向SSL認証

サーバーはクライアントに対して証明書を提示する必要があるが、クライアントはサーバーに対して証明書を提示する必要がないというSSL認証のタイプ。クライアントはサーバーを認証する必要がありますが、サーバーはどのクライアントの接続も受け入れます。WebLogic Serverではデフォルトで有効になっています。「相互認証」、「双方向SSL認証」も参照してください。

パスワード検証プロバイダ

パスワード構成ルール・セットを実行するように認証プロバイダで構成できるセキュリティ・プロバイダ。

境界認証

アプリケーション・サーバー・ドメインの外側で発生する認証。境界認証は通常、リモート・ユーザーがアサートされたIDと、検証の実行に使用される特定の形態の対応する証明データ(一般的にはパスフレーズの形態、具体的にはパスワード、クレジット・カード番号、暗証番号などの個人を識別する情報)を認証サーバー(一般的にはWebサーバー)に指定することによって行われます。認証サーバーは、検証を実行し、アーティファクトつまりトークンをアプリケーション・サーバー・ドメイン(WebLogic Serverドメインなど)に渡します。アプリケーション・サーバーはそのトークンをドメイン内のシステムで回すことができるため、ユーザーは何度もサインオンを求められることはありません。

認証エージェント(IDに対して実際に保証するエンティティ)は、仮想プライベート・ネットワーク(VPN)、ファイアウォール、エンタープライズ認証サービス(Webサーバー)、その他の形態のグローバルIDサービスなどの形式を取ることができます。

WebLogic Serverセキュリティ・アーキテクチャは、境界認証(Webサーバー、ファイアウォール、VPN)を実行して複数のセキュリティ・トークンのタイプやプロトコル(SOAP、IIOP-CSIv2)を扱うIDアサーション・プロバイダをサポートします。「認証」、「IDアサーション」も参照してください。

ポリシー条件

セキュリティ・ポリシーを作成する際の条件。ポリシー条件に対して特定の情報(実際のユーザー名、グループ、セキュリティ・ロール、開始/終了時間など)を指定したものは式と呼ばれます。「ポリシー文」も参照してください。

ポリシー式

「ポリシー文」を参照してください。

ポリシー文

誰にWebLogicリソースへのアクセス権が付与されるかを定義する式の集合。したがって、作成するセキュリティ・ポリシーの主要部分となります。ポリシー文は、ポリシー式とも呼ばれます。「ポリシー条件」も参照してください。

プリンシパル

認証の結果としてユーザー、グループ、またはシステム・プロセスに割り当てられるID。プリンシパルは、任意の数のユーザーまたはグループで構成できます。通常、プリンシパルはサブジェクトに格納されます。「認証」、「グループ」、「サブジェクト」、「ユーザー」も参照してください。

プリンシパル検証

署名し、その署名後にプリンシパルが変更されていないことを確認する行為。プリンシパル検証によってプリンシパルの信頼性が確立されます。「プリンシパル」も参照してください。

秘密鍵

秘密のメッセージを交換する当事者のみが知っている暗号化/復号化鍵。そのオーナー以外には非公開のまま保管する必要があるので、秘密鍵と呼ばれます。「公開鍵」も参照してください。

秘密鍵アルゴリズム

暗号テキストをエンコード(暗号化)するために使用される計算手順。秘密鍵で暗号化されたデータは、公開鍵を使用することによってのみ復号化できます。「秘密鍵」および「公開鍵」も参照してください。

プログラムによるセキュリティ

Javaメソッドを使用してサーブレットとEJBで定義されるアプリケーション・セキュリティ。

公開鍵

メッセージおよびデジタル署名を効果的に暗号化および復号化するために使用でき、秘密鍵と結合される、暗号化鍵/復号化鍵として認証局から提供される値。誰でも使用できるので、公開鍵と呼ばれます。公開鍵暗号方式は、データの暗号化と復号化に異なる鍵を使用するので、非対称鍵暗号方式とも呼ばれます。「非対称鍵暗号方式」、「秘密鍵」も参照してください。

公開鍵アルゴリズム

プレーン・テキストをエンコード(暗号化)するために使用される計算手順。公開鍵で暗号化されたデータは、秘密鍵を使用することによってのみ復号化できます。「秘密鍵」、「秘密鍵アルゴリズム」、「公開鍵」も参照してください。

公開鍵暗号方式

「非対称鍵暗号方式」を参照してください。

RDBMSセキュリティ・ストア

ドメイン内に構成され、セキュリティ・プロバイダがセキュリティ・データを格納するために使用されるデータストアを含む外部RDBMS。

リライイング・パーティ

Web SSOにおいて、アサーティング・パーティから提供されたアサーションを信頼すべきかどうかを判断する側。SAMLには、提供されたアサーションをリライイング・パーティが信頼できるようにするための複数のメカニズムが定義されています。リライイング・パーティが提供されたアサーションを信頼したとしても、そのサブジェクトがローカル・リソースにアクセスできるかどうかはローカル・アクセス・ポリシーで定義されます。したがって、ユーザーがDan Murphyであることをリライイング・パーティが信頼しても、Dan Murphyがドメイン内のすべてのリソースにアクセスできるとは限りません。「アサーティング・パーティ」、「IDプロバイダ」、「Security Assertion Markup Language (SAML)」、「シングル・サインオン」も参照してください。

リソース

「WebLogicリソース」を参照してください。

リソース・アダプタ

アプリケーション・サーバー(WebLogic Serverなど)やアプリケーション・クライアントで、エンタープライズ情報システム(EIS)に接続するために使用されるシステム・レベルのソフトウェア・ドライバ(コネクタともいいます)。リソース・アダプタには、Javaコンポーネントに加えて、必要な場合にはEISとの対話に必要なネイティブ・コンポーネントが含まれます。

WebLogic Java EEコネクタ・アーキテクチャは、EISベンダーおよびサード・パーティ・アプリケーション開発者が開発し、Java EEプラットフォーム仕様に準拠しているアプリケーション・サーバーにデプロイ可能なリソース・アダプタをサポートしています。

応答側サービス

SAMLへのリクエストを処理するSAMLソース・サイト上のURL。「SAMLソース・サイト」も参照してください。

ロール条件

セキュリティ・ロール(グローバルまたはスコープ)をユーザーまたはグループに付与する条件。ロール条件に対して特定の情報(実際のユーザー名、グループ、開始/終了時間など)を指定したものは式と呼ばれます。「セキュリティ・ポリシー」、「ロール・マッピング」を参照してください。

ロール式

ロール条件の作成時に指定する特定の情報。「ロール条件」を参照してください。

ロール・マッピング

WebLogicセキュリティ・サービスがセキュリティ・ロール条件とユーザーまたはグループを比較して、そのユーザーまたはグループにセキュリティ・ロールを動的に付与するかどうかを決定するプロセス。ロール・マッピングは実行時に、保護対象のWebLogicリソースに対するアクセス決定を下す直前に発生します。「アクセス決定」、「グループ」、「プリンシパル」、「ロール条件」、「セキュリティ・ロール」、「ユーザー」、「WebLogicリソース」、「WebLogicセキュリティ・サービス」も参照してください。

ロール・マッピング・プロバイダ

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宛先サイト

SAMLアサーションの受信側。「サービス・プロバイダ」も参照してください。

SAMLプロファイル

アサーションおよびプロトコル・メッセージの特定のフローの技術的な記述。SAMLを特定の目的に使用する方法を定義します。

SAMLソース・サイト

ユーザーが認証済みで、関連する属性が付与されていることをアサートするシステム(管理ドメイン)。SAMLソースになるのは、(SAML Web SSOプロファイルなどを使用して)ユーザーを認証するサイト、または(Web Services Security SAMLトークン・プロファイルなどを使用して)クライアントとして動作する際にIDを転送するサイトです。「IDプロバイダ」も参照してください。

スキーマ

データベースに格納されているデータに関連付けられたデータ構造。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 7.0以降では、セキュリティ・レルムはスコーピング・メカニズムとして機能します。各セキュリティ・レルムは、構成済のセキュリティ・プロバイダ、ユーザー、グループ、ロール、セキュリティ・ポリシーで構成されます。ドメイン・レルムでは複数のアクティブなセキュリティ・レルムを使用できますが、デフォルト・セキュリティ・レルムは1つのみであり、そのセキュリティ・レルムはドメイン管理用に使用されます。WebLogic Serverには、デフォルト・セキュリティ・レルムmyrealmが用意されています。新しいセキュリティ・レルムを構成して、これをデフォルトのセキュリティ・レルムとして設定できます。または、パーティションに固有の(デフォルトではない)セキュリティ・レルムを構成することもできます。「デフォルト・レルム」、「ドメイン構成ウィザード」、「セキュリティ・プロバイダ」、「WebLogicリソース」も参照してください。

セキュリティ・ロール

特定の条件に基づいてユーザーまたはグループに付与される、動的に計算される権限。グループとロールの違いは、グループがサーバー管理者によって割り当てられる静的なIDであるのに対し、ロールのメンバーシップはユーザー名、グループ・メンバーシップ、時刻などのデータに基づいて動的に計算されることです。セキュリティ・ロールは個々のユーザーまたはグループに付与されます。また、複数のロールを使用してWebLogicリソース用のセキュリティ・ポリシーを作成できます。セキュリティ・ロールを作成したら、そのロールとWebLogicリソースとの関連付けを定義します。この関連付け(セキュリティ・ポリシー)により、WebLogicリソースに誰がどのようにアクセスできるかが指定されます。「グローバル・ロール」、「グループ」、「ロール・マッピング」、「スコープ指定ロール」、「セキュリティ・ポリシー」、「ユーザー」、「WebLogicリソース」も参照してください。

Security Service Provider Interfaces (SSPI)

カスタム・セキュリティ・プロバイダを開発し、WebLogic Server Securityサービスと統合できるようにするWebLogicパッケージ・セット。これらのインタフェースは、WebLogicセキュリティ・プロバイダおよびカスタム・セキュリティ・プロバイダによって実装されます。WebLogicセキュリティ・フレームワークは、これらのインタフェースでメソッドを呼び出してセキュリティ操作を実行します。「セキュリティ・プロバイダ」、「WebLogicセキュリティ・フレームワーク」も参照してください。

サービス・プロバイダ

IDプロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム(管理ドメイン)。SAMLには、提供されたアサーションをサービス・プロバイダが信頼できるようにするための複数のメカニズムが定義されています。「リライイング・パーティ」も参照してください。

サーブレット認証フィルタ

コンテナ・ベースの認証にかわるJava EEフィルタ・オブジェクトの一意の実装。サーブレット認証フィルタは、ログインを実行するためのリモート・サイトへのリダイレクト、問合せ文字列からのログイン情報の抽出、およびブラウザとのログイン機能のネゴシエーションを実行して、クライアントを認証するための会話を制御します。

SPNEGO (Simple and Protected GSS-API Negotiation)メカニズム

Kerberos SSO環境への参加を可能にするプロトコル。

シングル・サインオン

ユーザーが一度アプリケーションにサインオンすれば、他の様々なアプリケーション・コンポーネントに(それらが独自の認証方式を使用している場合でも)アクセスできる機能。シングル・サインオンは、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制御フラグ」、「プリンシパル」、「ユーザー」も参照してください。

対称鍵暗号方式

データの暗号化と復号化に同一の鍵を使用する暗号化アルゴリズムを採用した鍵ベースの暗号方式。対称鍵暗号方式は、秘密鍵暗号方式とも呼ばれます。「非対称鍵暗号方式」も参照してください。

ターゲットURL

Web SSOの認証プロセスを開始するためにリクエストされたURL。「SAMLソース・サイト」も参照してください。

トークン

ユーザーまたはシステム・プロセスの認証プロセスの一部として生成されるアーティファクト。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)」、「信頼性のある(ルート)認証局」も参照してください。

ユーザー

認証が可能なエンティティ。ユーザーは、個人でも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セキュリティ・フレームワーク

セキュリティの施行を統合し、他のWebLogic Serverコンポーネントにセキュリティ・サービスとして提供するweblogic.security.serviceパッケージのインタフェース。セキュリティ・プロバイダは、セキュリティ・サービスを必要とするアプリケーションのかわりにWebLogicセキュリティ・フレームワークに働きかけます。「セキュリティ・プロバイダ」も参照してください。

WebLogicセキュリティ・プロバイダ

WebLogic Server製品の一部としてOracleによって提供されるセキュリティ・プロバイダ。これらのプロバイダは、Security Service Provider Interfaces (SSPI)を使用してWebLogic Server向けに開発されています。「カスタム・セキュリティ・プロバイダ」、「セキュリティ・プロバイダ」、「Security Service Provider Interfaces (SSPI)」も参照してください。

WebLogicセキュリティ・サービス

セキュリティ・アーキテクチャを実装するWebLogic Serverサブシステム。このサブシステムは、WebLogicセキュリティ・フレームワーク、Security Service Provider Interfaces (SSPI)、およびWebLogicセキュリティ・プロバイダという3つの主要なコンポーネントで構成されています。

WebLogicサーバー・ドメイン

1つの構成ファイルで定義された、サーバー、サービス、インタフェース、マシン、および関連するWebLogicリソース・マネージャの集合。「WebLogicリソース」も参照してください。

Windows NT認証プロバイダ

認証のためにWindows NTのユーザーとグループを使用する認証プロバイダ。

Windows NTセキュリティ・レルム

WebLogic Server 6.xのセキュリティ・レルム。Windows NTセキュリティ・レルムでは、Windows NTドメイン向けに定義されたアカウント情報を使用して、ユーザーとグループを認証します。「認証」、「認可」、「グループ」、「セキュリティ・レルム」、「ユーザー」も参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。