| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解 11g リリース1(10.3.6) B61618-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解 11g リリース1(10.3.6) B61618-04 |
|
前 |
次 |
この章では、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インタフェースを実装する必要があります。
クライアントが認証の必要なアプリケーション、アプレット、Enterprise JavaBean (EJB)、あるいはサーブレットのいずれであろうと、WebLogic Serverでは、JAAS (Java Authentication and Authorization Service)クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。JAASは、プラガブル認証モジュール(PAM)フレームワークのJavaバージョンを実装します。このフレームワークにより、アプリケーションは基底の認証技術から独立することができます。このため、PAMフレームワークを利用することで、アプリケーションに修正を加えることなく新しいまたは更新された認証技術を使用することができます。
WebLogic Serverは、リモートのファット・クライアントの認証および内部の認証でJAASを使用します。したがって、JAASに直に関与する必要があるのは、カスタム認証プロバイダの開発者とリモート・ファット・クライアント・アプリケーションの開発者だけです。シン・クライアントのユーザーまたはコンテナ内のファット・クライアント・アプリケーション(サーブレットからEnterprise 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 WebLogic Serverセキュリティ・プロバイダの開発』の「カスタム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 2.3仕様で定義されているように、フィルタはリクエストやレスポンスを変更できるオブジェクトです。フィルタは、リクエストがサーブレットに届く前のプリプロセッサ、またはサーブレットから離れたレスポンスのポストプロセッサとして機能します。フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化できます。
フィルタは、コンテナ・ベースの認証のかわりとして使用できますが、この設計にはいくつかの欠点があります。
JavaサーブレットAPI 2.3仕様で指定されているように、フィルタは認証と認可の後に実行されます。認証にフィルタを使用する場合は、コンテナ管理の認可が使用されないようにするため、認可にもフィルタを使用する必要があります。サーブレット・コンテナでの認証処理で拡張機能が必要になるほとんどのケースでも、認可処理には拡張機能が必要とされません。フィルタに認可処理を実装しなければならないのは、煩雑で時間もかかり、間違いも発生しやすくなります。
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の保護』の次の項を参照してください。
WebLogicセキュリティ・プロバイダの構成
SSLの構成
ユーザー名/パスワード認証では、ユーザーIDとパスワードをユーザーにリクエストし、WebLogic Serverに送ります。WebLogic Serverは受け取った情報をチェックして、信頼性を確認できれば、保護されているWebLogicリソースへのアクセスを許可します。
Secure Sockets Layer (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認証プロバイダでサポートされています。 |
ダイジェスト認証を使用すると、Webサービスのセキュリティ・パスワード・ダイジェストのサポートに必要なパスワード情報を格納できます。
ダイジェスト認証を使用している場合、クライアントがサーバーに対して未認証のリクエストを行うと、サーバーはダイジェスト認証をサポートしていることを示すダイジェスト認証チャレンジを含むレスポンスを送信します。クライアントは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トークン・プロファイルは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 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サービスを構成する場合、管理コンソールでは、IDプロバイダのかわりに「ソース・サイト」という用語を使用しています。 |
サービス・プロバイダ - IDプロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム(管理ドメイン)。SAMLには、提供されたアサーションをサービス・プロバイダが信頼できるようにするための複数のメカニズムが定義されています。サービス・プロバイダは、リライイング・パーティまたは宛先サイトとも呼ばれ、しばしばSPと略されます。
サービス・プロバイダが提供されたアサーションを信頼したとしても、そのサブジェクトがローカル・リソースにアクセスできるかどうかはローカル・アクセス・ポリシーで定義されます。したがって、ユーザーがDan Murphyであることをサービス・プロバイダが信頼しても、Dan Murphyがドメイン内のすべてのリソースにアクセスできるとは限りません。
WebLogic Serverインスタンスをサービス・プロバイダのロールで機能するように構成できます。その場合、IDプロバイダ・パートナとの信頼関係を確立する必要があります。WebLogic Serverでは、SAML IDアサーション・プロバイダがこの機能を提供します(構成する特定のIDアサーション・プロバイダは、使用するSAMLのバージョンに固有です)。
WebLogic ServerインスタンスでSAML 1.1サービスを構成する場合、管理コンソールでは、サービス・プロバイダのかわりに「宛先サイト」という用語を使用しています。
アサーションは、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では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)を参照してください。
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プロバイダ(管理コンソールでは「ソース・サイト」)として機能するWebLogic Serverインスタンスのために構成する必要があります。 |
|
SAML 1.1 |
SAML資格証明マッピング・プロバイダ・バージョン1 |
SAML 1.1アサーションを生成します(非推奨)。 |
|
SAML 1.1 |
SAML IDアサーション・プロバイダ・バージョン2 |
SAML 1.1アサーションを消費します。このプロバイダは、サービス・プロバイダ(管理コンソールでは「宛先サイト」)として機能する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の保護』の「SAML認証プロバイダの構成」を参照してください。) |
WebLogic Serverは、SAML IDプロバイダ(IdP)またはサービス・プロバイダ(またはその両方)として機能するように構成できます。IdPとして機能させる場合、IdPがアサーションを生成できるようにSAML資格証明マッピング・プロバイダを構成する必要があります。サービス・プロバイダとして機能させる場合、サービス・プロバイダがアサーションを消費できるようにSAML IDアサーション・プロバイダを構成する必要があります。
SAMLシングル・サインオン・サービス(SSO)はサーバー単位で構成します。クラスタなど、ドメイン内の複数のサーバーでSAML SSOを有効にするには、次の方法をお薦めします。
RDBMSセキュリティ・ストアが構成されているドメインを作成します。詳細は、『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構成の他のサイトでも自動的に認証されるので、別個にログインする必要がありません。
|
注意: 管理コンソールを使用してSAMLを構成する場合、いくつかのSAMLエントリの名前がSAML 1.1と2.0では異なります。この節では、主な用語の違いについて説明しています。 |
以下の手順は、SAML SSOの動作を示す一般的なシナリオを示しています。
Webユーザーが、SAMLアサーションを介して認証を受け付けるよう構成されているサイトのターゲット・リソースにアクセスしようとします。
管理コンソールで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を含むEnterprise JavaBeans (EJB) JAR、そのJAR内の特定のEnterprise JavaBeans (EJB)、そのEJB内の単一のメソッドなどに対してセキュリティ・ロールとセキュリティ・ポリシーを定義できます。
以下のWebLogicリソースの実装を使用できます。
管理リソース
アプリケーション・リソース
コンポーネント・オブジェクト・モデル(COM)リソース
エンタープライズ情報システム(EIS)リソース
Enterprise JavaBeans (EJB)リソース
Java Database Connectivity (JDBC)リソース
Java Message Service (JMS)リソース
Java Naming and Directory Interface (JNDI)リソース
サーバー・リソース
Webアプリケーション・リソース
Webサービス・リソース
ワーク・コンテキスト・リソース
セキュリティ・ポリシーはアクセス制御リスト(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は、リソース・コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール・マッピング決定を行うセキュリティ・プロバイダに渡す高性能なWebLogicクラスです。ContextHandlerインタフェースを使用すると、内部WebLogicリソース・コンテナでWebLogic Securityフレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandlerは本質的には名前と値のリストなので、セキュリティ・プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandlerの使用には、WebLogicリソース・コンテナとセキュリティ・プロバイダの間の緊密な連携が不可欠です。ContextHandlerの名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElementオブジェクトによって表されます。
現在、3種類のWebLogicリソース・コンテナ(サーブレット・コンテナ、EJBコンテナ、Webサービス・コンテナ)がContextHandlerをWebLogic Securityフレームワークに渡します。これらのコンテキスト要素の値は、裁決プロバイダ、IDアサーション・プロバイダ、認可プロバイダ、資格証明マッピング・プロバイダ、およびロール・マッピング・プロバイダで調べるか、認証プロバイダで使用するLoginModuleで調べることができます。監査イベントをポストするためにセキュリティ・プロバイダが実装される場合に使用するAuditContextインタフェースの実装によっても、コンテキスト要素の値を調べることができます。
特定のコンテキスト要素の値に関する詳細は、『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 WebLogic Serverの保護』の「SSLの構成」を参照してください。
デジタル証明書は、認証局によって発行されます。デジタル証明書および公開鍵の発行先のIDを保証する信頼性のある第三者組織または企業はすべて、認証局になることができます。認証局は、デジタル証明書を作成する際に、証明書が改ざんされればわかるように秘密鍵を使って署名します。認証局は、署名したデジタル証明書をリクエスト側に返します。
要求側は、認証局の公開鍵を使って発行認証局の署名を確認します。認証局の公開鍵は、低レベル認証局の公開鍵の妥当性を保証する高レベル認証局から発行された証明書を提供することで利用できるようになります。この方式によって、認証局の階層が構築されます。この階層は、最終的に、ルート証明書と呼ばれる、最上位の自己署名証明書にたどり着きます。この証明書では、証明にそれ以外の一切の公開鍵が不要です。ルート証明書は、信頼性のある(ルート)認証局によって発行されます。
受信側がすでに信頼性を確認済みの、該当認証局よりも高レベルの認証局が署名した該当認証局の公開鍵が入ったデジタル証明書を持っている場合、暗号化されたメッセージの受信側は、認証局の公開鍵を再帰的に信頼します。この点では、デジタル証明書はデジタルの信頼関係の踏み台です。結局、信頼する必要があるのは、ごく少数の最上位認証局の公開鍵だけです。証明書のチェーンを通じて、多数のユーザーのデジタル署名の信頼を確立できます。
通信中のエンティティのIDは、このようにしてデジタル署名によって確立できますが、デジタル署名による信頼は、信頼性を確認するための公開鍵の範囲にとどまります。
詳細は、『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を使用して作成されています。
WebLogic Serverは、Webを介して接続されたアプリケーション間のセキュリティが保護された通信を可能にするSSL通信を完全サポートしています。今回のWebLogic Serverのリリースには、次の使用に対するSSLスタックとしてJava Secure Socket Extension (JSSE)を使用するためのサポートが含まれます。
受信時SSL接続
WebLogic SSLのAPIを使用する送信時SSL接続(アプリケーションは常に送信SSL接続に対してJSSEを直接呼び出すことが可能でした)。
|
注意: WebLogic Serverを最新リリースにアップグレードする際にユーザー側の混乱を最小限に抑えるため、Certicom SSL実装が引き続きデフォルトになっています。ただし、Certicom SSL実装は現在では非推奨で、将来のリリースでは削除されます。速やかにJSSEを使用することをお薦めします。JSSEの詳細情報は、次の場所にある『Java Secure Socket Extension (JSSE)リファレンス・ガイド』を参照してください。
|
この節では、以下の内容について説明します。
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と通信する場合は、Hypertext Transfer Protocol with SSL (HTTPS)を利用して、ネットワーク通信の安全性を確保できます。
暗号スイートとは、認証、鍵の同意、暗号化、および整合性保護で使用されるセキュリティ・アルゴリズムおよび鍵サイズを定義する暗号化パラメータの組合せです。
暗号スイートは、通信の整合性を保護します。たとえば、RSA_WITH_RC4_128_MD5という暗号スイートは、鍵交換用のRSA、一括暗号化用の128ビット鍵を持つRC4、およびメッセージ・ダイジェスト用のMD5を使用します。
WebLogic Serverによってサポートされる暗号スイートの設定は、次のようにWebLogic Serverの構成時に使用されるSSL実装に依存します。
JDKデフォルトJSSEプロバイダによってサポートされる暗号スイートの設定であるSunJSSEは、次の場所にある『Java(tm) Secure Socket Extension (JSSE)リファレンス・ガイド』で参照できます。
http://download.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
JSSEベースのSSL実装を使用するためのWebLogic Serverの構成の詳細は、『Oracle WebLogic Serverの保護』のJSSEベースのSSL実装の使用に関する項を参照してください。
以前のリリースのWebLogic ServerではCerticom SSL実装を使用していましたが、この実装はWebLogic Serverでまだ使用できますが、現在は非推奨です。対称鍵強度を含むCerticom SSL実装によってサポートされる暗号スイートは、表3-2にリストで表示されています。
表3-2 Certicom暗号スイート
| 暗号スイート | 対称鍵強度(ビット) |
|---|---|
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA |
168 |
TLS_DHE_RSA_WITH_DES_CBC_SHA |
56 |
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA |
40 |
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA |
168 |
TLS_DH_anon_WITH_RC4_128_MD5 |
128 |
TLS_DH_anon_WITH_DES_CBC_SHA |
56 |
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 |
40 |
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA |
40 |
TLS_DHE_RSA_EXPORT_WITH_DES_40_CBC_SHA |
40 |
TLS_DH_anon_EXPORT_WITH_DES_40_CBC_SHA |
40 |
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_DES_40_CBC_SHAFoot 1 |
40 |
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA |
40 |
TLS_RSA_WITH_3DES_EDE_CBC_SHA |
168 |
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 |
脚注1 この暗号スイートは、TLS_RSA_EXPORT_WITH_DES40_CBC_SHAの別名です。
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は、管理コンソールを使用して構成します。
デフォルトでは、WebLogic Serverは一方向のSSL認証用に構成されますが、SSLポートは無効化されています。管理コンソールを使用すると、双方向の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が証明書の参照と検証を使用するかどうかを制御できます。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のトラスト・マネージャの使用に関する項およびCertPathトラスト・マネージャの使用に関する項を参照してください。
Federal Information Processing Standards (FIPS) 140-2は、アメリカ合衆国政府の機密でも未分類の使用に関する要件を記載した規格です。WebLogic Serverは、RSA Crypto-JライブラリのかわりにサーバーのSSL実装でFIPS準拠(FIPS 140-2)暗号化モジュールを使用するための機能をサポートします。詳細は、『Oracle WebLogic Serverの保護』の「SSLの設定: 主な手順」を参照してください。
ファイアウォールとは、2つのネットワーク間のトラフィックを制限する機能のことです。ファイアウォールは、ソフトウェアとハードウェア(ルーターや専用のゲートウェイ・マシンなど)を組み合せて作成できます。ファイアウォールは、プロトコル、リクエストされたサービス、ルーティング情報、および送信元と送信先のホストまたはネットワークに基づいてトラフィックの通過を許可または拒否するフィルタを利用します。また、認証されたユーザーについてもアクセスを許可する場合があります。
図3-4に、WebLogic Serverクラスタ宛てのトラフィックをフィルタ処理するファイアウォールを使った代表的な設定を示します。
WebLogic Serverでは、ファイアウォールと組み合せて、以下の機能を使用できます。
WebLogic Server接続フィルタを使用して、プロトコル、IPアドレス、およびDNSノード名に基づいてネットワーク・トラフィックをフィルタ処理するファイアウォールを設定できます。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』の「ネットワーク接続フィルタの使い方」を参照してください。
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セキュリティのサポートにより、アプリケーションの開発者は、セキュリティ領域の最新の強化拡張と開発を利用できます。このため、企業投資を主にJavaプログラミング技術に活用できます。定義され、ドキュメントされたJava標準に従うことで、WebLogic Serverのセキュリティ・サポートではJava開発者に対する共通の基準が確立されます。WebLogic Serverによって提供される新技術は、Java SE 5.0のサポートに基づいています。
この節では、以下の内容について説明します。
WebLogic Serverは、以下のJava EE 6.0セキュリティ・パッケージに準拠し、それらのパッケージをサポートしています。
JSSEは、SSLとTLS v1プロトコルをサポートおよび実装し、それらのプロトコルの機能をプログラムで利用可能にするパッケージのセットです。WebLogic Serverでは、WebLogic Serverクライアント、および他のサーバーとの間で転送されるデータを暗号化するために、Secure Sockets Layer (SSL)がサポートされています。
JAASは、ユーザー・ベースの認証およびアクセス制御のためのフレームワークを提供するパッケージのセットです。WebLogic Serverでは、JAASの認証用クラスだけを使用します。
|
注意: WebLogic Serverドメインには、JAAS認可(環境に必要な場合)の使用に影響を与えるセキュリティ構成設定があります。このセキュリティ構成を設定する必要がある場合の詳細は、『Oracle WebLogic Serverの保護』の「JAAS認可を使用するドメインの構成」を参照してください。 |
JAASは以下の場合に使用されます。
リモートJavaクライアント認証
WebコンテナやEJBコンテナ内、およびWebLogic認証プロバイダやIDアサーション・プロバイダ内におけるWebLogic Serverインスタンス間の内部認証
JAASの詳細は、「JAAS (Java Authentication and Authorization Service)」を参照してください。
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セキュリティ・マネージャの使用方法の詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』の「Javaセキュリティ・マネージャを使用してのWebLogicリソースの保護」を参照してください。
これらのセキュリティ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クラスは、Java SE 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 WebLogic Serverクラスタの使用』の「サーバー・アフィニティとCSIv2を使用したIIOPクライアント認証」を参照してください。 |
