Oracle® Fusion Middleware Oracle WebLogic Server Security について 11g リリース 1 (10.3.1) B55519-01 |
|
![]() 戻る |
![]() 次へ |
この章では、WebLogic Server のセキュリティに関する以下の基礎概念について説明します。
監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査はコンピュータのアクティビティの電子的な記録を提供するものです。WebLogic Server のセキュリティ アーキテクチャでは、監査プロバイダを使用して監査サービスを提供します。
監査プロバイダがコンフィグレーションされている場合、ドメイン コンフィグレーションに変更が加えられるか、ドメイン内のいずれかのリソースで管理操作が呼び出されると、セキュリティ操作 (認証や認可など) が実行される前とされた後に、WebLogic Security フレームワークが監査プロバイダを呼び出します。個々のイベントを監査するかどうかの決定は監査プロバイダによって行われ、特定の監査基準または重大度レベルあるいはその両方に基づいて決定することができます。監査情報を記載した記録は、LDAP サーバ、データベース、シンプル ファイルなどの出力リポジトリに書き出すことができます。
認証とは、呼び出し側が、特定のユーザまたはシステムの代わりに動作していることを証明する際に使用するメカニズムのことです。認証は、ユーザ名とパスワードの組み合わせなどの資格を使用して「あなたは誰」という問いに答えます。
WebLogic Server では、ユーザまたはシステム プロセスの ID を証明するために認証プロバイダを使用します。認証プロバイダでは、ID 情報を記憶したり、転送したり、その情報が必要な場合に (サブジェクトを通じて) システムのさまざまなコンポーネントで利用できるようにしたりします。認証プロセスでは、プリンシパル検証プロバイダが、サブジェクト内に格納されるプリンシパル (ユーザおよびグループ) のセキュリティを強化するため、それらのプリンシパルに署名して信頼性を検証します。
以下の節では、認証の概念と機能について説明します。
サブジェクトとプリンシパルは密接に関係しています。
プリンシパルは、認証の結果としてユーザまたはグループに割り当てられる ID です。WebLogic Server のようなアプリケーション サーバでは、ユーザもグループもプリンシパルとして使用することができます。JAAS (Java Authentication and Authorization Service) では、プリンシパルなどの認証情報のコンテナとしてサブジェクトを使用することになっています。
図 3-1 に、ユーザ、グループ、プリンシパル、およびサブジェクト間の関係を示します。
認証に成功すると、その一環として、プリンシパルは署名され、その後の使用に備えてサブジェクトに格納されます。プリンシパルに署名するのはプリンシパル検証プロバイダであり、実際にプリンシパルをサブジェクトに格納するのは LoginModule です。後で、サブジェクト内に格納されたプリンシパルに呼び出し側がアクセスしようとすると、そのプリンシパルが署名されてから変更されていないことをプリンシパル検証プロバイダが確認したうえで、そのプリンシパルが呼び出し側に返されます (それ以外のセキュリティ条件がすべて満たされている場合)。
WebLogic Server ユーザまたはグループを表すプリンシパルは、weblogic.security.spi
パッケージの WLSUser
インタフェースと WLSGroup
インタフェースを実装する必要があります。
クライアントが認証の必要なアプリケーション、アプレット、エンタープライズ JavaBean (EJB)、あるいはサーブレットのいずれであろうと、WebLogic Server では、JAAS (Java Authentication and Authorization Service) クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。JAAS は、プラグイン可能な認証モジュール (PAM) フレームワークの Java バージョンを実装します。このフレームワークにより、アプリケーションは基底の認証技術から独立することができます。このため、PAM フレームワークを利用することで、アプリケーションに修正を加えることなく新しいまたは更新された認証技術を使用することができます。
WebLogic Server は、リモートのファット クライアントの認証および内部の認証で JAAS を使用します。したがって、JAAS に直に関与する必要があるのは、カスタム認証プロバイダの開発者とリモート ファット クライアント アプリケーションの開発者だけです。シン クライアントのユーザまたはコンテナ内のファット クライアント アプリケーション (サーブレットからエンタープライズ JavaBeans を呼び出すものなど) の開発者は、JAAS を直接使用したり、その知識を身につけたりする必要はありません。
LoginModule は、認証処理における「馬車馬」のような存在です。すべての LoginModule は、セキュリティ レルム内のユーザの認証と、サブジェクト内への必要なプリンシパル (ユーザ/グループ) の格納を担当します。境界認証に使用されない LoginModule も、提示された証明情報 (たとえば、ユーザのパスワード) が正しいかどうかを確認します。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、各認証プロバイダの LoginModule は同じサブジェクトにプリンシパルを格納します。したがって、ある認証プロバイダの LoginModule によって、WebLogic Server ユーザ (WLSUser
インタフェースの実装) を表すプリンシパル「Joe」が追加された場合、セキュリティ レルム内の他のすべての認証プロバイダは、「Joe」に出会ったときに同じ人物を参照する必要があります。つまり、他の認証プロバイダの LoginModule は、同じ人物を参照するために、WebLogic Server ユーザを表す別のプリンシパル (「Joseph」など) をサブジェクトに追加しようとしてはなりません。ただし、別の認証プロバイダの LoginModule は、WLSUser
以外のタイプのプリンシパルを「Joseph」という名前で追加することができます。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、認証プロバイダの制御フラグ属性で認証プロバイダの実行順序を決定します。次に、制御フラグ属性の値を示します。
REQUIRED - この LoginModule は成功する必要があります。失敗しても、認証はコンフィグレーションされている認証プロバイダの LoginModule リストにある次の LoginModule に進みます。これはデフォルト設定です。
REQUISITE - この LoginModule は成功する必要があります。他の認証プロバイダがコンフィグレーションされている場合、この LoginModule が成功すると、認証は LoginModule リストにある次の LoginModule に進みます。それ以外の場合、制御はアプリケーションに戻されます。
SUFFICIENT - この LoginModule は成功する必要はありません。成功した場合、制御はアプリケーションに戻されます。他の認証プロバイダがコンフィグレーションされている場合、この LoginModule が失敗すると、認証は LoginModule リストにある次の LoginModule に進みます。
OPTIONAL - ユーザはこの認証プロバイダの認証テストを通過することも失敗することもできます。ただし、セキュリティ レルムでコンフィグレーションされているすべての認証プロバイダで JAAS の [制御フラグ] 属性が [OPTIONAL] に設定されている場合、ユーザはコンフィグレーション済みプロバイダのいずれかの認証テストを通過する必要があります。
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 認証」を参照してください。
LoginModule と一緒に用いると、ID アサーション プロバイダはシングル サインオンをサポートします。たとえば、ID アサーション プロバイダは SAML アサーションを処理できるため、ユーザがサインオンを複数回求められることはありません。
ID アサーション プロバイダが使用する LoginModule では、以下のことが可能です。
開発したカスタム認証プロバイダの一部となる。
Oracle が開発して WebLogic Server と一緒にパッケージ化した WebLogic 認証プロバイダの一部となる。
サード パーティのセキュリティ ベンダの認証プロバイダの一部となる。
単純認証の場合と違って、ID アサーション プロバイダが使用する LoginModule は証明データ (ユーザ名とパスワードなど) を検証しません。単にユーザが存在することを検証するだけです。
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 Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』の「カスタム ID アサーション プロバイダを開発する必要があるか」を参照してください。 |
チャレンジ ID アサーション スキーマにより、複数のチャレンジ、応答メッセージ、および状態が規定されます。WebLogic Server のセキュリティ レルムには、Microsoft の Windows NT チャレンジ/応答 (NTLM)、SPNEGO (Simple and Protected GSS-API Negotiation)、その他のチャレンジ/応答認証メカニズムなどの認証プロトコルをサポートするセキュリティ プロバイダを設定できます。WebLogic Server には、ネゴシエート ID アサーション プロバイダという SPNEGO セキュリティ プロバイダが付属しています。NTLM や他のチャレンジ/応答認証メカニズムを実装するセキュリティ プロバイダを開発してデプロイすることも可能です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』を参照してください。
Java サーブレット API 2.3 仕様で定義されているように、フィルタはリクエストや応答を変更できるオブジェクトです。フィルタは、リクエストがサーブレットに届く前のプリプロセッサ、またはサーブレットから離れた応答のポストプロセッサとして機能します。フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化できます。
フィルタは、コンテナベースの認証の代わりとして使用できますが、この設計にはいくつかの欠点があります。
Java サーブレット API 2.3 仕様で指定されているように、フィルタは認証と認可の後に実行される。認証にフィルタを使用する場合は、コンテナ管理の認可が使用されないようにするため、認可にもフィルタを使用する必要があります。サーブレット コンテナでの認証処理で拡張機能が必要になるほとんどのケースでも、認可処理には拡張機能が必要とされません。フィルタに認可処理を実装しなければならないのは、煩雑で時間もかかり、間違いも発生しやすくなります。
J2EE フィルタは、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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の以下の節を参照してください。
ユーザ名/パスワード認証では、ユーザ ID とパスワードをユーザに要求し、WebLogic Server に送ります。WebLogic Server は受け取った情報をチェックして、信頼性を確認できれば、保護されている WebLogic リソースへのアクセスを許可します。
セキュア ソケット レイヤ (SSL)、または Hyper-Text Transfer Protocol with SSL (HTTPS) を使用すると、ユーザ名/パスワード認証にさらに高度なレベルのセキュリティを提供できます。SSL は、クライアントと WebLogic Server との間で転送されるデータを暗号化するので、ユーザ ID とパスワードはクリア テキストでは転送されません。したがって、WebLogic Server は、ユーザの ID およびパスワードの機密性を保持したままユーザを認証できます。
SSL または HTTPS クライアントのリクエストが送信されると、WebLogic Server は、クライアントに対してデジタル証明書を提示して応答します。クライアントによってそのデジタル証明書が確認されると、SSL 接続が確立されます。デジタル証明書は、WebLogic Server の身元を検証するエンティティ (信頼性のある認証局) によって発行されます。
相互認証の一形態である、双方向の SSL 認証を使用することもできます。双方向の SSL 認証では、クライアントとサーバの両方が証明書を提示しないと、両者の間で接続スレッドが有効になりません。「一方向および双方向 SSL 認証」を参照してください。
注意 : 双方向の SSL 認証は、WebLogic Server 製品の一部として提供される WebLogic 認証プロバイダでサポートされています。 |
ダイジェスト認証を使用している場合、クライアントがサーバに対して未認証のリクエストを行うと、サーバはダイジェスト認証をサポートしていることを示すダイジェスト認証チャレンジを含む応答を送信します。クライアントは nonce を生成し、タイムスタンプ、ダイジェスト、およびユーザ名とともにサーバに送信します。ダイジェストは、パスワード、nonce、およびタイムスタンプの暗号ハッシュです。クライアントは、ユーザ名と、パスワードに nonce 値を組み合わせた暗号ハッシュを送信して、リソースを再度要求します。サーバはハッシュ自体を生成し、生成されたハッシュがリクエスト内のハッシュと一致していればリクエストを許可します。
ダイジェスト認証の利点は、リプレイ攻撃への耐性があることです。ダイジェスト認証を実装すると、使用された nonce とタイムスタンプのキャッシュが指定の期間保持されます。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonce ペアと同じタイムスタンプ/nonce ペアを使用するリクエストもすべて拒否されます。WebLogic Server では、このキャッシュはデータベースに格納されます。パフォーマンスを向上させるため、コマンドライン オプションを使用してこのキャッシュを無効にすることもできます。
境界認証は、アプリケーション サーバ ドメインの外側にいるリモート ユーザの ID を認証するプロセスです。
以下の節では、境界認証について説明します。
境界認証は通常、リモート ユーザが断定された ID と、検証の実行に使用される特定の形態の対応する証明データ (一般的にはパスフレーズの形態、具体的にはパスワード、クレジット カード番号、暗証番号などの個人を識別する情報) を指定することによって行われます。
実際に ID を保証するエンティティである、認証エージェントは、さまざまな形態を取ることができます。たとえば、仮想プライベート ネットワーク (VPN)、ファイアウォール、企業認証サービスといったグローバルな ID サービスの形態を取ることができます。認証エージェントのこれらの形態には共通の特徴があります。これらはすべて、認証を受けたユーザに関する情報を調べるために後で提示する必要があるアーティファクトつまりトークンを生成するという認証プロセスを実行します。現時点では、トークンの形式はベンダごとに異なりますが、XML を使用した標準のトークン形式の定義が進められています。さらに、属性証明書に対しては、デジタル証明書用の X.509 標準に基づいた標準があります。しかし、結局のところ、アプリケーションやそれが構築されているインフラストラクチャがこの概念をサポートするよう設計されていない場合は、企業のネットワーク内のアプリケーションに対してリモート ユーザは再認証を行う必要があります。
WebLogic Server は、ID アサーションのサポートを介して境界までシングル サインオン概念を拡張できるよう設計されています (図 3-2 を参照)。WebLogic Security フレームワークの重要な部分として提供される ID アサーションの概念により、SAML (Security Assertion Markup Language)、SPNEGO (Simple and Protected GSS-API Negotiation)、または CSI (Common Secure Interoperability) v2 を始めとするプロトコルへの拡張など、境界認証方式によって提供される認証メカニズムを使用して WebLogic Server でこの機能を実現できます。
境界認証をサポートするには、1 つまたは複数のトークン フォーマットをサポートするように設計された ID アサーション プロバイダを使用する必要があります。複数の異なる ID アサーション プロバイダを登録して使用できます。トークンは、WebLogic Server がサポートするさまざまなプロトコルによって提供されるメカニズムを使用して、通常のビジネス リクエストの一部として転送されます。WebLogic Server でリクエストが受け取られると、プロトコル メッセージを処理するエンティティによってメッセージ内のトークンが認識されます。この情報は、WebLogic Security フレームワークの呼び出しに使用されます。WebLogic Security フレームワークは、トークンの検証を処理する適切な ID アサーション プロバイダを呼び出します。トークンを検証し、そのトークンの信頼性を確立するために必要なすべてのアクションの実行と、保証されたユーザ ID の提供は、ID アサーション プロバイダ実装によって行われます。ユーザはアプリケーションに対して再認証を行う必要がありません。
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 Token Profile は 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 Administration Console で表示される対応するエンティティについては、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 サービスをコンフィグレーションする場合、Administration Console では、ID プロバイダの代わりに「ソース サイト」という用語を使用しています。 |
サービス プロバイダ - ID プロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム (管理ドメイン)。SAML には、提供されたアサーションをサービス プロバイダが信頼できるようにするための複数のメカニズムが定義されています。サービス プロバイダは、「依頼側」または「送り先サイト」とも呼ばれます。また、SP と簡略化されることもあります。
サービス プロバイダが提供されたアサーションを信頼したとしても、そのサブジェクトがローカル リソースにアクセスできるかどうかはローカル アクセス ポリシーで定義されます。したがって、ユーザが Dan Murphy であることをサービス プロバイダが信頼しても、Dan Murphy がドメイン内のすべてのリソースにアクセスできるとは限りません。
WebLogic Server インスタンスをサービス プロバイダのロールで機能するようにコンフィグレーションできます。その場合、ID プロバイダ パートナとの信頼関係を確立する必要があります。WebLogic Server では、SAML ID アサーション プロバイダがこの機能を提供します (コンフィグレーションする特定の ID アサーション プロバイダは、使用する SAML のバージョンに固有です)。
WebLogic Server インスタンスで SAML 1.1 サービスをコンフィグレーションする場合、Administration Console では、サービス プロバイダの代わりに「送り先サイト」という用語を使用しています。
アサーションは、ID プロバイダによって作成された 1 つまたは複数の文を提供する情報のパッケージです。以下の種類の文がサポートされます。
サブジェクトが認証された時間と方法を示す認証文
サブジェクト固有の情報 (サブジェクトが属すグループなど) を提供する属性文
サブジェクトに何を許可するかを示す認可文
注意 : WebLogic Server での SAML アサーションについては、次の点に注意してください。
|
プロトコル - SAML では、アサーションを取得するためのリクエスト/応答プロトコルが定義されています。SAML リクエストでは、特定の既知のアサーションを要求するか、認証または属性を決定するためのクエリを実行できます。SAML 応答では要求されたアサーションが返されます。プロトコル メッセージの XML 形式と使用可能な拡張は、XML スキーマで定義されています。
WebLogic Server では、認証リクエスト プロトコルがサポートされています。このプロトコルでは、認証応答 (つまり、<Response>
文を含むメッセージ) を返信させる認証リクエスト (つまり、<AuthnRequest>
文を含むメッセージ) が定義されます。認証応答には、プリンシパルに関連するアサーションが含まれます。
通常、認証リクエストはサービス プロバイダから ID プロバイダに送信され、その結果、認証応答が返されます。認証リクエスト プロトコルは、Web ブラウザの SSO プロファイル サポートに使用されます。
バインディング - バインディングには、SAML プロトコルが転送可能な低レベルの通信プロトコルまたはメッセージング プロトコル (HTTP や SOAP など) が定義されています。バインディングは、SAML プロトコルが転送プロトコルおよびメッセージング プロトコルにどのようにマップしているかを詳細に示します。たとえば、SAML <AuthnRequest>
メッセージの HTTP へのマッピングなどを示します。
SAML 1.1 の場合、WebLogic Server では Web SSO プロファイルの HTTP POST および HTTP アーティファクト バインディングがサポートされます。SAML 2.0 の場合、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
) を参照。
SAML 1.1 および 2.0 のサポートは、次の WebLogic Server コンポーネントで提供されます。
SAML セキュリティ プロバイダ
シングル サインオン サービス
Web サービスでの SAML Token Profile 1.1 のサポート
WebLogic Server では、SAML 1.1 および 2.0 をサポートするために次のセキュリティ プロバイダが付属しています。
表 3-1 SAML をサポートするために WebLogic Server に付属しているセキュリティ プロバイダ
サポート対象 | プロバイダ | 説明 |
---|---|---|
SAML 1.1 |
SAML 資格マッピング プロバイダ バージョン 2 |
SAML 1.1 アサーションを生成する。このプロバイダは、ID プロバイダ (Administration Console では「ソース サイト」) として機能する WebLogic Server インスタンスのためにコンフィグレーションする必要がある。 |
SAML 1.1 |
SAML 資格マッピング プロバイダ バージョン 1 |
SAML 1.1 アサーションを生成する (非推奨)。 |
SAML 1.1 |
SAML ID アサーション プロバイダ バージョン 2 |
SAML 1.1 アサーションを消費する。このプロバイダは、サービス プロバイダ (Administration Console では「送り先サイト」) として機能する 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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の「SAML 認証プロバイダのコンフィグレーション」を参照)。 |
WebLogic Server は、SAML ID プロバイダ (IdP) またはサービス プロバイダ (またはその両方) として機能するようにコンフィグレーションできます。IdP として機能させる場合、IdP がアサーションを生成できるように SAML 資格マッピング プロバイダをコンフィグレーションする必要があります。サービス プロバイダとして機能させる場合、サービス プロバイダがアサーションを消費できるように SAML ID アサーション プロバイダをコンフィグレーションする必要があります。
SAML シングル サインオン サービス (SSO) はサーバ単位でコンフィグレーションします。クラスタなど、ドメイン内の複数のサーバで SAML SSO を有効にするには、次の方法をお勧めします。
RDBMS セキュリティ ストアがコンフィグレーションされているドメインを作成します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「RDBMS セキュリティ ストアの管理」を参照してください。
SSO サービスが、各サーバ インスタンスでまったく同じようにコンフィグレーションされていることを確認します。
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 アサーション プロバイダのいずれか) をコンフィグレーションする必要があります。
シングル サインオンは、ユーザが一度アプリケーション コンポーネントにサインオンすれば、他のさまざまなアプリケーション コンポーネントに (それらが独自の認証方式を使用している場合でも) アクセスできる機能です。シングル サインオンを使用すると、ユーザはすべてのアプリケーション、Web サイト、メインフレーム セッションに、1 つの ID でセキュアにログインできます。WebLogic Server では、以下の環境でのシングル サインオン (SSO) が可能です。
Security Assertion Markup Language (SAML) を使用すると、WebLogic Server ドメインで実行されている Web アプリケーションまたは Web サービスと、Web ブラウザまたはその他の HTTP クライアントの間でクロスプラットフォーム認証を実行できます。WebLogic Server では SAML に基づくシングル サインオン (SSO) がサポートされています。シングル サインオン (SSO) コンフィグレーションに参加する 1 つのサイトでユーザが認証されると、SSO コンフィグレーションの他のサイトでも自動的に認証されるので、別個にログインする必要がありません。
注意 : Administration Console を使用して SAML をコンフィグレーションする場合、いくつかの SAML エントリの名前が SAML 1.1 と 2.0 では異なります。この節では、主な用語の違いについて説明しています。 |
以下の手順は、SAML SSO の動作を示す一般的なシナリオを示しています。
Web ユーザが、SAML アサーションを介して認証を受け付けるようコンフィグレーションされているサイトの対象リソースにアクセスしようとします。
Administration Console で SAML 1.1 をコンフィグレーションする場合、このサイトは「送り先サイト」と呼ばれます。SAML 2.0 では、「サービス プロバイダ」と呼ばれます。
サービス プロバイダは、ユーザの資格を、そのユーザの SAML アサーションを生成できる中央サイトで認証する必要があるかどうかを判別します。サービス プロバイダは、認証リクエストをその中央サイトにリダイレクトします。
SAML 1.1 では、SAML アサーションを生成するサイトは「ソース サイト」と呼ばれます。SAML 2.0 では、「ID プロバイダ」と呼ばれます。SAML のバージョンに関係なく「SAML 権限」と呼ぶ場合もあります。
ユーザが ID プロバイダにログインします。ログインは通常、そのサイトによってホストされるログイン Web アプリケーションを介して行います。ID プロバイダはユーザを認証し、SAML アサーションを生成します。
ID プロバイダによって提供され、ユーザと対象リソースに関連付けられた SAML アサーションの情報が、プロトコル交換によって ID プロバイダからサービス プロバイダに転送されます。
一連の HTTP 交換を経て、ユーザのブラウザがサービス プロバイダのアサーション コンシューマ サービス (ACS) に転送されます。WebLogic Server の SAML ID アサーション プロバイダが ACS の一部を構築します。
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 Security フレームワークによるシングル サインオン」を参照してください。
デスクトップ クライアントでの 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 リソースは、基底の WebLogic Server エンティティを表す構造化オブジェクトです。セキュリティ ロールとセキュリティ ポリシーを使用すると、これらのオブジェクトを権限のないアクセスから保護できます。
WebLogic リソースは階層化されています。このため、セキュリティ ロールとセキュリティ ポリシーは自由なレベルで定義できます。たとえば、エンタープライズ アプリケーション (EAR) 全体、複数の EJB を含むエンタープライズ JavaBean (EJB) JAR、その JAR 内の特定のエンタープライズ JavaBean (EJB)、その EJB 内の単一のメソッドなどに対してセキュリティ ロールとセキュリティ ポリシーを定義できます。
以下の WebLogic リソースの実装を使用できます。
管理リソース
アプリケーション リソース
コンポーネント オブジェクト モデル (COM) リソース
エンタープライズ情報システム (EIS) リソース
エンタープライズ JavaBean (EJB) リソース
Java Database Connectivity (JDBC) リソース
Java Message Service (JMS) リソース
Java Naming and Directory Interface (JNDI) リソース
サーバ リソース
Web アプリケーション リソース
Web サービス リソース
ワーク コンテキスト リソース
注意 : これらの WebLogic リソースの各実装の詳細については、WebLogic クラスの Javadoc を参照してください。 |
セキュリティ ポリシーはアクセス制御リスト (ACL) に代わるもので、「誰が WebLogic リソースにアクセスできるか」という問いに答えるものです。セキュリティ ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールとの間に関連付けを定義するときに作成されます。また、セキュリティ ポリシーに日時制約を定義することもできます。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。
セキュリティ ポリシーは、定義済みの任意の WebLogic リソース (EJB リソースや JNDI リソースなど)、または WebLogic リソースの特定のインスタンス (Web アプリケーション内の EJB メソッドやサーブレット) の属性または操作に割り当てることができます。セキュリティ ポリシーを WebLogic リソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ ポリシーは、WebLogic リソースのタイプに割り当てられたセキュリティ ポリシーをオーバーライドします。定義済みの WebLogic リソースのリストについては、「WebLogic リソース」を参照してください。
セキュリティ ポリシーは、認可プロバイダのデータベースに格納されます。デフォルトでは、XACML 認可プロバイダがドメイン内にコンフィグレーションされ、セキュリティ ポリシーは組み込み LDAP サーバに格納されます。
ユーザまたはグループを使用してセキュリティ ポリシーを作成する場合は、そのユーザまたはグループがデフォルト セキュリティ レルムでコンフィグレーションされた認証プロバイダのセキュリティ プロバイダ データベースで定義されていなければなりません。セキュリティ ロールを使用してセキュリティ ポリシーを作成する場合は、そのセキュリティ ロールがデフォルト セキュリティ レルムでコンフィグレーションされたロール マッピング プロバイダのセキュリティ プロバイダ データベースで定義されていなければなりません。XACML 認証プロバイダおよびロール マッピング プロバイダは、デフォルトでは組み込み LDAP サーバ内のデータベースにコンフィグレーションされています。
デフォルトで、WebLogic Server には WebLogic リソース用のセキュリティ ポリシーが定義されています。これらのセキュリティ ポリシーは、セキュリティ ロールとデフォルト グローバル グループに基づいています。また、必要に応じてセキュリティ ポリシーはユーザに基づくこともできます。ただし、セキュリティ ポリシーは、ユーザまたはグループではなく、セキュリティ ロールに基づいて作成することをお勧めします。セキュリティ ロールに基づいてセキュリティ ポリシーを作成すると、ユーザまたはグループに付与されるセキュリティ ロールに基づいてアクセスを管理できます。管理の方法としてはこちらの方が効率的です。WebLogic リソースのデフォルト セキュリティ ポリシーのリストについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「デフォルトのルート レベルのセキュリティ ポリシー」を参照してください。
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler
インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement
オブジェクトによって表されます。
現在、3 種類の WebLogic リソース コンテナ (サーブレット コンテナ、EJB コンテナ、Web サービス コンテナ) が ContextHandler を WebLogic Security フレームワークに渡します。そのため、URL (Web)、EJB、および Web サービスの各リソース タイプには、異なるコンテキスト要素が含まれます。これらのコンテキスト要素の値は、裁決プロバイダ、ID アサーション プロバイダ、認可プロバイダ、資格マッピング プロバイダ、およびロール マッピング プロバイダで調べるか、認証プロバイダで使用する LoginModule で調べることができます。監査イベントをポストするためにセキュリティ プロバイダが実装される場合に使用する AuditContext
インタフェースの実装によっても、コンテキスト要素の値を調べることができます。
特定のコンテキスト要素の値に関する詳細については、『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』の「ContextHandler と WebLogic リソース」を参照してください。
認証プロバイダの LoginModule と同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作を WebLogic リソースに対して実行するパーミッションをサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答を PERMIT
、DENY
、または ABSTAIN
のいずれかで返します。
裁決では、セキュリティ レルムで複数の認可プロバイダがコンフィグレーションされている場合に発生するおそれのある認可上の衝突を、それぞれの認可プロバイダのアクセス決定の結果を比較検討することによって解消します。WebLogic Server では、裁決プロバイダを使用して、複数のアクセス決定から返される結果を調停し、PERMIT
か DENY
の最終判定を下します。また、裁決プロバイダでは、単一の認可プロバイダのアクセス決定から ABSTAIN
の回答が返されたときにどうすべきかを指定することもできます。
プライベート キー、デジタル証明書、および信頼性のある認証局によって、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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照してください。
デジタル証明書は、認証局によって発行されます。デジタル証明書および公開鍵の発行先の ID を保証する信頼性のある第三者組織または企業はすべて、認証局になることができます。認証局は、デジタル証明書を作成する際に、証明書が改ざんされればわかるようにプライベート キーを使って署名します。認証局は、署名したデジタル証明書を要求側に返します。
要求側は、認証局の公開鍵を使って発行認証局の署名を確認します。認証局の公開鍵は、低レベル認証局の公開鍵の妥当性を保証する高レベル認証局から発行された証明書を提供することで利用できるようになります。この方式によって、認証局の階層が構築されます。この階層は、最終的に、ルート証明書と呼ばれる、最上位の自己署名証明書にたどり着きます。この証明書では、証明にそれ以外の一切の公開鍵が不要です。ルート証明書は、信頼性のある (ルート) 認証局によって発行されます。
受信側がすでに信頼性を確認済みの、該当認証局よりも高レベルの認証局が署名した該当認証局の公開鍵が入ったデジタル証明書を持っている場合、暗号化されたメッセージの受信側は、認証局の公開鍵を再帰的に信頼します。この点では、デジタル証明書はデジタルの信頼関係の踏み台です。結局、信頼する必要があるのは、ごく少数の最上位認証局の公開鍵だけです。証明書のチェーンを通じて、多数のユーザのデジタル署名の信頼を確立できます。
通信中のエンティティの ID は、このようにしてデジタル署名によって確立できますが、デジタル署名による信頼は、信頼性を確認するための公開鍵の範囲にとどまります。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「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 を使用して作成されています。
SSL を使用することで、Web を介して接続されるアプリケーション間のセキュアな通信が可能になります。
このリリースの WebLogic Server では、Certicom SSLPlus Java バージョン 4.0 SSL の実装を使用します。RSA Cert-J および Crypto-J は、Cert-J バージョン 2.1.1 および Crypto-J バージョン 3.5 にアップグレードされています。
WebLogic Server では、SSL 通信が完全にサポートされています。デフォルトでは、一方向 SSL 認証がコンフィグレーションされていますが、SSL ポートは無効になっています。Administration Console を使用して、WebLogic Server に対して双方向 SSL 認証をコンフィグレーションできます。
クライアントからサーバへの一方向 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 アプリケーションをホストしているシステムの名前) のように指定します。
この節では、以下の内容について説明します。
WebLogic Server では、SSL の pure-Java 実装が提供されます。一般的に、SSL は以下の機能を提供します。
通信を行うアプリケーションが互いの身元を認証するために利用するメカニズム
アプリケーション間でやり取りするデータの暗号化
SSL を使用する場合、対象 (サーバ) は常に発信元 (クライアント) に対して自身を認証します。対象が要求した場合は、発信元が対象に対して自身を認証することもあります。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。SSL 接続はデジタル証明書をやり取りするアプリケーション間のハンドシェークで始まり、使用する暗号化アルゴリズムの取り決め、そのセッションの残りで使用する暗号鍵の生成と続きます。
具体的には、SSL が提供するセキュリティ機能は以下のとおりです。
サーバ認証 - WebLogic Server は、信頼性のある認証局が発行したデジタル証明書を使用して、クライアントに対して認証します。SSL では最低でも、サーバが自身のデジタル証明書を使用してクライアントに対して認証を行うことが必要になります。デジタル証明書の提示がクライアントに要求されない場合の接続タイプは、いわゆる一方向 SSL 認証です。
クライアント ID の検証 - 場合によっては、WebLogic Server に対するデジタル証明書の提示がクライアントに要求されることもあります。WebLogic Server で、そのデジタル証明書が信頼性のある認証局によって発行されたものであることが確認されると、SSL 接続が確立されます。デジタル証明書が提示されなかったり、確認されなかったりした場合、SSL 接続は確立されません。この接続タイプは、相互認証の一形態である、いわゆる双方向の SSL 認証です。
機密性 - クライアントのリクエストとサーバの応答は暗号化され、ネットワーク経由でやり取りされるデータの機密性が保持されます。
データの整合性 - 各 SSL メッセージには、元のデータから計算されたメッセージ ダイジェストが含まれます。受け手側では、解読されたデータから新しいダイジェストを計算し、メッセージとともに受信したダイジェストと比較します。データが変更されているとダイジェストが一致せず、改ざんが検出されます。
クライアントと WebLogic Server 間のデータ フローの、第三者のユーザ ID 検証による改ざんからの保護。
Web ブラウザを使って WebLogic Server と通信する場合は、Hypertext Transfer Protocol with SSL (HTTPS) を利用して、ネットワーク通信の安全性を確保できます。
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 接続します。
WebLogic Server では、一方向と双方向の SSL 認証がサポートされています。一方向 SSL 認証では、対象 (サーバ) が発信元 (クライアント) に対してデジタル証明書を提示して身元を証明する必要があります。クライアントは、2 つのチェックを行って、デジタル証明書を検証します。
証明書が信頼できるか (つまり、クライアントの信頼性のある CA によって発行されたか)、有効か (期限切れでないか)、その他の証明書制約を満たすかをクライアントが検証します。
証明書のサブジェクトの共通名 (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 は、Administration Console を使用してコンフィグレーションします。
ホスト名検証は、SSL 接続先のホスト名が予定していた通信先、または許可された通信先であることを確認するプロセスです。Web クライアント (Web ブラウザ、WebLogic クライアント、またはクライアントとして機能している WebLogic Server) が別のアプリケーション サーバとの SSL 接続を要求する場合に、介在者の攻撃を防ぎます。
SSL クライアントの SSL ハンドシェーク機能としてのデフォルトの動作は、SSL サーバのデジタル証明書の SubjectDN にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。これらの名前が一致しない場合は SSL 接続が中断されます。
トラスト マネージャは、デフォルトの SSL 信頼検証ルールをオーバーライドする方法を提供します。トラスト マネージャにより、サーバにアクセスしてきたクライアントを信頼するかどうかをサーバが決定できます。トラスト マネージャを使用すると、SSL 接続を続行する前にカスタム検証を実行できます。たとえば、トラスト マネージャを使用して、特定の地域 (町、州、国など) のユーザやその他の特殊な属性を持つユーザだけが SSL 接続を介してアクセスを取得できるように指定することができます。
WebLogic Server は、weblogic.security.SSL.TrustManager
インタフェースを提供します。このインタフェースを使用すると、SSL ハンドシェークの間に、トラスト マネージャのカスタム実装を呼び出すことができます。カスタム実装では、SSL 実装の検証チェックによって検出されたハンドシェーク エラーをオーバーライドしたり、独自の証明書ルールに基づいてエラーを発生させたりできます。
WebLogic Server には、weblogic.security.SSL.CertPath.TrustManager
インタフェースも用意されています。アプリケーションやカスタム コードでこのインタフェースを使用すると、発信 SSL で証明書の検索と検証を使用するかどうかを制御できます。
注意 : このインタフェースは、このリリースの WebLogic Server で非推奨になった weblogic.security.SSL.TrustManagerJSSE インタフェースの代わりに使用します。 |
非対称鍵 (公開鍵ともいう) アルゴリズムは、公開鍵、プライベート キーという数学的には互いに関連性を持ちながらも異なる 2 つの鍵を利用します。
公開鍵 (一般に配布) は、デジタル署名を検証したり、データを外見上解釈不能な形式に変換したりするために使用される。
プライベート キー (非公開のまま保管) は、デジタル署名を作成したり、データを元の形式に戻したりするために使用される。
WebLogic Server の公開鍵インフラストラクチャ (PKI) でもデジタル署名のアルゴリズムがサポートされています。デジタル署名アルゴリズムは、デジタル署名を生成するためだけの公開鍵アルゴリズムのことです。
WebLogic Server では、Rivest-Shamir-Adelman (RSA) アルゴリズムがサポートされています。
対称鍵アルゴリズムでは、メッセージの暗号化と復号化に同じ鍵を使用します。共通鍵暗号化システムは対称鍵アルゴリズムを使用して、通信中の 2 つのエンティティ間でやり取りされるメッセージを暗号化します。通常は、対称暗号方式のほうが非対称暗号方式よりも高速です。
ブロック暗号は、プレーン テキスト (暗号化されていないテキスト) の固定長ブロックを同じ長さの暗号テキスト (暗号化済みテキスト) データ ブロックに変換する対称鍵アルゴリズムの一種です。この変換は、ランダムに生成したセッション キーの値に従って発生します。固定長はブロック サイズと呼ばれます。
WebLogic Server の PKI は以下の対称鍵アルゴリズムをサポートしています。
DES-CBC (Data Encryption Standard - Cipher Block Chaining)
DES-CBC は、Cipher Block Chaining (CBC) モードの 64 ビット ブロックの暗号文です。56 ビットの鍵を使用します (8 パリティ ビットがフル 64 ビット鍵から除去されます)。
2 キー形式トリプル DES (Data Encryption Standard)
2 キー形式トリプル DES は、Encrypt-Decrypt-Encrypt (EDE) モードの 128 ビット ブロックの暗号です。2 キー形式トリプル DES では、2 つの 56 ビット鍵 (実効では 112 ビットの鍵 1 つ) を利用します。
現在では、トリプル DES による DES 暗号鍵を保護および転送する方式が一般的となっています。つまり、入力データ (この場合にはシングル DES 鍵) を暗号化し、解読してから、もう一度暗号化します (暗号化 - 復号化 - 暗号化処理)。同じ鍵を 2 回の暗号化処理に使います。
RC4 (Rivest's Cipher 4)
RC4 は、サイズが 40 ~ 128 ビットの鍵を使用する可変キー サイズ ブロック暗号です。DES よりも高速です。
注意 : ユーザは、このアルゴリズムのリストを拡張したり変更したりすることができません。 |
WebLogic Server は、MD5 および SHA (Secure Hash Algorithm) メッセージ ダイジェスト アルゴリズムをサポートしています。MD5 も SHA も、広く知られた一方向のハッシュ アルゴリズムです。一方向のハッシュ アルゴリズムは、メッセージを、メッセージ ダイジェストまたはハッシュ値と呼ばれる数字の固定文字列に変換します。
MD5 は高速処理可能な 128 ビット ハッシュで、32 ビット マシンで使用することを想定しています。MD5 と比べて、SHA は 160 ビット ハッシュを用いてより高度なセキュリティを提供しますが、処理速度は低下します。
暗号スイートとは、鍵交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア ハッシュ アルゴリズムを含む SSL 暗号方式の一種です。通信の整合性を保護するために使用します。たとえば、RSA_WITH_RC4_128_MD5
という暗号スイートは、鍵交換用に RSA、バルク暗号化用に 128 ビット鍵を使う RC4、およびメッセージ ダイジェスト用に MD5 を使用します。
FIPS140 の検証状態を http://csrc.nist.gov/cryptval/
の検証リストで確認します。
WebLogic Server でサポートされている RSA 暗号スイートは、表 3-2 のとおりです。
表 3-2 WebLogic Server でサポートされている SSL 暗号スイート
暗号スイート | 対称鍵の強度 |
---|---|
TLS_RSA_WITH_RC4_128_SHA |
128 |
TLS_RSA_WITH_RC4_128_MD5 |
128 |
TLS_RSA_WITH_DES_CBC_SHA |
56 |
TLS_RSA_EXPORT_WITH_RC4_40_MD5 |
40 |
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA |
40 |
TLS_RSA_WITH_3DES_EDE_CBC_SHA |
112 |
TLS_RSA_WITH_NULL_SHA |
0 |
TLS_RSA_WITH_NULL_MD5 |
0 |
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA |
56 |
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA |
56 |
TLS_RSA_WITH_AES_128_CBC_SHA |
128 |
TLS_RSA_WITH_AES_256_CBC_SHA |
256 |
ファイアウォールとは、2 つのネットワーク間のトラフィックを制限する機能のことです。ファイアウォールは、ソフトウェアとハードウェア (ルータや専用のゲートウェイ マシンなど) を組み合わせて作成できます。ファイアウォールは、プロトコル、要求されたサービス、ルーティング情報、および送信元と送信先のホストまたはネットワークに基づいてトラフィックの通過を許可または拒否するフィルタを利用します。また、認証されたユーザについてもアクセスを許可する場合があります。
図 3-4 に、WebLogic Server クラスタ宛てのトラフィックをフィルタ処理するファイアウォールを使った代表的な設定を示します。
WebLogic Server では、ファイアウォールと組み合わせて、以下の機能を使用できます。
WebLogic Server 接続フィルタを使用して、プロトコル、IP アドレス、および DNS ノード名に基づいてネットワーク トラフィックをフィルタ処理するファイアウォールを設定できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照してください。
ID アサーション プロバイダを使用して、境界認証 (トークンを使用する特別なタイプの認証) を設定できます。WebLogic Server のセキュリティ アーキテクチャは、境界に基づく認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティ トークン タイプ/プロトコル (SOAP、SAML、SPNEGO、IIOP-CSIv2) を処理する ID アサーション プロバイダをサポートします。
ユーザ認証とユーザ認可を実装および使用するために、WebLogic Server では、JDK バージョン 6.0 のセキュリティ サービスが利用されます。他の Java EE コンポーネントと同様、セキュリティ サービスも標準化されたモジュール コンポーネントに基づいています。WebLogic Server は、標準に従ってこれらの Java セキュリティ サービス メソッドを実装し、細かなアプリケーションの動作をプログラミングを必要とせずに自動的に処理する拡張を追加します。
WebLogic Server の Java EE 6.0 セキュリティのサポートにより、アプリケーションの開発者は、Sun Microsystems のセキュリティ領域の最新の強化拡張と開発を利用できます。このため、企業投資を主に Java プログラミング技術に傾注できます。定義され、文書化された Java 標準に従うことで、WebLogic Server のセキュリティ サポートでは Java 開発者に対する共通の基準が確立されます。WebLogic Server によって提供される新技術は、J2SE 5.0 のサポートに基づいています。
この節では、以下の内容について説明します。
WebLogic Server は、以下の Java EE 6.0 セキュリティ パッケージに準拠し、それらのパッケージをサポートしています。
JSSE は、SSL と TLS v1 プロトコルをサポートおよび実装し、それらのプロトコルの機能をプログラムで利用可能にするパッケージのセットです。WebLogic Server では、WebLogic Server クライアント、および他のサーバとの間で転送されるデータを暗号化するために、セキュア ソケット レイヤ (SSL) がサポートされています。
JSSE は SSL 機能のクラスのコア セットを提供し、Certicom などの企業はそれらのクラスに対する拡張を提供します。WebLogic Server では、SSL の実装に Certicom JSSE 拡張を使用します。
JAAS は、ユーザベースの認証およびアクセス制御のためのフレームワークを提供するパッケージのセットです。WebLogic Server では、JAAS の認証用クラスだけを使用します。
JAAS は以下の場合に使用されます。
リモート Java クライアント認証
Web コンテナや EJB コンテナ内、および WebLogic 認証プロバイダや ID アサーション プロバイダ内における WebLogic Server インスタンス間の内部認証
JAAS の詳細については、「JAAS (Java Authentication and Authorization Service)」を参照してください。
Java セキュリティ マネージャは、Sun Microsystems, Inc. によって開発された、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 セキュリティ マネージャの使用方法の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
Sun Microsystems, Inc. によって開発された、これらのセキュリティ API は、Java プラットフォーム向けの暗号機能へのアクセスおよび暗号機能の開発と、暗号、鍵の生成と照合、および Message Authentication Code (MAC) アルゴリズムの実装の開発に使用するフレームワークを提供します。
WebLogic Server ではこれらのセキュリティ API が完全にサポートされています。
JACC は、WebLogic Server ドメイン内の EJB およびサーブレット コンテナに代替認可メカニズムを提供します。JACC がコンフィグレーションされている場合、WebLogic Security フレームワークのアクセス決定、裁決、およびロール マッピング機能は、EJB およびサーブレットの認可判定には使用されません。JACC クラスは、ロールとプリンシパルのマッピングだけでなく、アクセス決定を返すためにも使用します。WebLogic Security フレームワークと一緒に JACC フレームワークを使用することはできません。WebLogic Server で使用される JACC クラスには、決定を下すためのポリシー オブジェクトの実装は含まれません。代わりに、JACC クラスは、J2SE 1.4 java.security.Policy
オブジェクトに依存します。
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 Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ アフィニティと CSIv2 を使用した IIOP クライアント認証」を参照してください。 |