1. Oracle WebLogic Serverのセキュリティの理解
  2. セキュリティの基礎概念

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

監査、認証、認可、IDと信頼、Security Assertion Markup Language (SAML)などのWebLogic Serverの基礎的なセキュリティ概念について学習します。

監査

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

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

認証

認証とは、ユーザーまたはシステム・プロセスの識別情報を導出するプロセスです。WebLogic Serverには、認証プロバイダを介して認証サービスが提供されています。認証の概念と機能について学習します。

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

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

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

ノート:

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

  • Java EE Security API (JSR 375)を認証に使用する方法の詳細は、「Java EE Security API」を参照してください。

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

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

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

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

図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セキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

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

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

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 Server配布キットに含まれているWebLogic認証プロバイダでは、以下のタイプの認証がサポートされています。

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

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

ユーザー名/パスワード認証では、ユーザー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では、SAMLおよびSPNEGO境界認証方式がサポートされています。

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

境界認証の仕組み

境界認証は通常、リモート・ユーザーがアサートされた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 境界認証

図3-2の説明が続きます
「図3-2 境界認証」の説明

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

SAML (Security Assertion Markup Language)

SAMLは、Webアプリケーションに対してシングル・サインオン機能を提供してユーザーIDが共有および保護できるようにし、ソフトウェア・エンティティ間でのID情報の交換を可能にします。WebLogic Serverは、SAML 2.0、SAML Web SSOプロファイルおよびWeb Services SAMLトークン・プロファイルをサポートします。

ノート:

SAML 1.1 IDアサーション・プロバイダ、SAML 1.1資格証明マッピング・プロバイダ、およびSAML 1.1フェデレーション・サービスに関連する構成とサービスは、WebLogic Server 14.1.2.0.0で非推奨になりました。将来のリリースで削除されます。SAML 2.0を使用することをお薦めします。

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

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

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

SAMLは、OASIS (Organization for the Advancement of Structured Information Standards)によって開発され、このリリースのWebLogic Serverでは、次のサポートを含むSAML 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フレームワークの概念

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

ノート:

これらの概念の用語は、SAML 1.1と2.0の間で多少異なります。

  • IDプロバイダ - ユーザーが認証済みで、関連する属性が付与されていることをアサートするシステム(管理ドメイン)。たとえば、John Doeというユーザーがいて、john.doe@example.comという電子メール・アドレスを持っており、パスワード・メカニズムによってこのドメインに認証されました。IDプロバイダは、SAML認証局、アサーティング・パーティ、またはソース・サイトとも呼ばれ、しばしばIdPと略されます。

    WebLogic ServerインスタンスをIDプロバイダのロールで機能するように構成できます。IDプロバイダは発行者URI (名)によって認識されます。WebLogic Serverでは、SAML資格証明マッピング・プロバイダがこの機能を提供します。(構成する特定の資格証明マッピング・プロバイダは、使用するSAMLのバージョンに固有です。)

  • サービス・プロバイダ - IDプロバイダによって提供されたアサーションを信頼するかどうかを決定するシステム(管理ドメイン)。SAMLには、提供されたアサーションをサービス・プロバイダが信頼できるようにするための複数のメカニズムが定義されています。サービス・プロバイダは、リライイング・パーティまたは宛先サイトとも呼ばれ、しばしばSPと略されます。

    サービス・プロバイダが提供されたアサーションを信頼したとしても、そのサブジェクトがローカル・リソースにアクセスできるかどうかはローカル・アクセス・ポリシーで定義されます。したがって、ユーザーがDan Murphyであることをサービス・プロバイダが信頼しても、Dan Murphyがドメイン内のすべてのリソースにアクセスできるとは限りません。

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

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

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

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

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

      ノート:

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

      • 属性文は、グループ情報を含めることのみを目的としてサポートされます。SAML認証プロバイダは、SAMLアサーションからグループ情報を取得できます(『Oracle WebLogic Serverセキュリティの管理』の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アーキテクチャへのこれらの概念の適用については、次のトピックを参照してください。

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 14.1.2.0.0で非推奨になりました。

SAML 1.1

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

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

ノート: このプロバイダは、WebLogic Server 14.1.2.0.0で非推奨になりました。

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を有効にするには、次の方法をお薦めします。

  1. RDBMSセキュリティ・ストアが構成されているドメインを作成します。『Oracle WebLogic Serverセキュリティの管理』の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)

シングル・サインオン(SSO)によって、ユーザーは一度アプリケーションにセキュアにログインすれば、他の様々なアプリケーション・コンポーネントに(これらのコンポーネントが独自の認証方式を使用している場合でも)アクセスできるようになります。

WebLogic Serverでは、以下の環境でのシングル・サインオン(SSO)が可能です。

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

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

ノート:

  • SAML 1.1 IDアサーション・プロバイダ、SAML 1.1資格証明マッピング・プロバイダ、およびSAML 1.1フェデレーション・サービスに関連する構成とサービスは、WebLogic Server 14.1.2.0.0で非推奨になりました。将来のリリースで削除されます。SAML 2.0を使用することをお薦めします。

  • SAMLを構成する場合、いくつかのSAMLエントリの名前がSAML 1.1と2.0では異なります。この節では、主な用語の違いについて説明しています。

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

  1. Webユーザーが、SAMLアサーションを介して認証を受け付けるよう構成されているサイトのターゲット・リソースにアクセスしようとします。

    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標準の基本情報については、次のトピックを参照してください。

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では、認可プロバイダがセキュリティ・ポリシー、ContextHandlers、アクセス決定などの概念を使用して認可を提供します。認可プロバイダを使用して、ユーザーとWebLogicリソースとの対話を制限して、整合性、機密性、および可用性を確保します。

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

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セキュリティの管理』の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セキュリティの管理』のSSLの構成に関する項を参照してください。

証明書の検索と検証

WebLogic Serverでは、証明書の検証は証明書検索および検証(CLV)フレームワークによって実行されます。このフレームワークは、着信双方向SSL、発信SSL、アプリケーション・コード、およびWebLogic Webサービスについて、X.509証明書チェーンを完了および検証します。

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

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

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

Secure Sockets Layer (SSL)

WebLogic Serverは、インターネットを介して接続されたアプリケーション間でセキュリティが保護された通信を可能にするSSL通信を完全サポートしています。WebLogic Serverは、受信接続さらにWebLogic SSLのAPIを使用する発信接続のセキュリティを保護するためのSSL実装としてJava Secure Socket Extension (JSSE)を使用します。

WebLogic Serverでホストされているアプリケーションは、さらにアウトバウンドSSL接続についてJSSEを直接に呼び出せます。

ノート:

WebLogic Serverバージョン12.1.1以降では、サポートされるSSL実装はJSSEのみになります。CerticomベースのSSL実装はなくなり、WebLogic Serverでサポートされなくなりました。

JSSEの詳細は、『Jakarta SEセキュリティ開発者ガイド』のJava Secure Socket Extension (JSSE)リファレンス・ガイドを参照してください。

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

SSLの機能

WebLogic Serverでは、SSLのpure-Java実装が提供されます。SSLは、互いのIDを認証するために通信アプリケーションが利用するメカニズム、およびアプリケーション間でやり取りするデータの暗号化を提供します。

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によってサポートされる暗号化スイート・セットは、次のURLからダウンロードできます:

JSSEベースのSSL実装を使用するためのWebLogic Serverの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』の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/TLS認証

WebLogic Serverでは、一方向と双方向のSSL/TLS認証がサポートされています。

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

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

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

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

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

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

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

図3-3の説明が続きます
「図3-3 WebLogic ServerがSSL/TLS接続をサポートする仕組み」の説明

SSL/TLSの構成

デフォルトでは、WebLogic Serverは一方向のSSL/TLS認証用に構成されますが、SSL/TLSポートは無効化されています。

WebLogicリモート・コンソールまたはWLSTを使用すると、双方向のSSL/TLS認証用にWebLogic Serverを構成できます。

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

  • クライアントとサーバーの間の双方向SSL/TLSを使用するには、サーバーの双方向SSL/TLSを有効にし、サーバーの信頼とサーバーのIDを構成します。

    どちらの場合も、ピアのID証明書を発行した信頼性のあるCA証明書が、信頼性のあるCA証明書に含まれている必要があります。この証明書は、ルートCA証明書でなくても構いません。

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

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

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

本番環境でSSL/TLSを構成するためのその他のガイドラインについては、『Oracle WebLogic Server本番環境の保護』のSSL/TLSの構成を参照してください。

ホスト名検証

ホスト名検証は、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セキュリティの管理』のFIPSモードの有効化に関する項を参照してください。

ファイアウォール

ファイアウォールは、信頼できるネットワークと信頼できないネットワーク間の壁の役割を果たすことでネットワーク・トラフィックを制御します。ファイアウォールとともにWebLogic Serverネットワーク・チャネルの接続フィルタおよび境界認証を使用して、ユーザーおよびネットワーク情報に基づいてリソースへのアクセスを制限できます。

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

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

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

図3-4の説明が続きます
「図3-4 代表的なファイアウォールの設定」の説明

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

ソフトウェアおよびハードウェアを使用して、ファイアウォール、受信および送信アプリケーション・トラフィックを分離するネットワーク・チャネルなどのコンポーネント、およびネットワーク・レベルでアクセスを拒否する接続フィルタを作成して、環境のネットワークを保護する方法の詳細は、『Oracle WebLogic Server本番環境の保護』のネットワーク接続の保護に関する項を参照してください。

ネットワーク・チャネル

ネットワーク・チャネルは、ネットワークがサポートするプロトコル、リスニング・アドレス、セキュアな通信およびセキュアでない通信のリスニング・ポートなど、WebLogic Serverへのネットワーク接続の属性を定義します。

ネットワーク・チャネルを使用することで、管理者はWebLogic Serverへのネットワーク・アクセスの公開を詳細に制御できます。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

接続フィルタ

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

境界認証

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

Java EEとWebLogicセキュリティ

WebLogic Serverでは、ユーザー認証とユーザー認可を実装および使用するために、JDKのセキュリティ・サービスが利用されます。WebLogic Serverは、Java SEおよびJava EEセキュリティ・パッケージをサポートし、さらに、EJB相互運用性プロトコルのサポートを提供します。

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

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

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

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

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

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セキュリティの管理』の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リモート・コンソール またはWLSTを使用して、Webアプリケーションのデプロイ後の操作用にJASPICを有効化します。

SAMで作成されたプリンシパルのカスタム検証方法を含む、WebアプリケーションでのJASPICの使用方法の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebアプリケーションでのJASPICの使用に関する項を参照してください。

Java EE Security API (JSR 375)

Java EE Security API (JSR 375)仕様(https://www.jcp.org/en/jsr/detail?id=375)では、認証およびアイデンティティ・ストア用の移植可能なプラグイン・インタフェースや、プログラムによるセキュリティのためのAPIを提供する注入可能なSecurityContextインタフェースを定義しています。プラグインSPIの組込み実装を使用することも、カスタム実装を記述することもできます。

WebLogic Serverでは、Webアプリケーション・コンテナ(Webサービスを含む)内でこれらの認証メカニズムがサポートされ、サーブレットおよびEJBコンテナ内でSecurityContextインタフェースがサポートされています。

WebLogic ServerでJava EE Security APIを使用する方法の詳細は、『WebLogic Security Serviceによるアプリケーションの開発』のJava EE Security APIの使用に関する項を参照してください。

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をサポートすることにより、以下のことが可能になります。

  • Java Platform, Enterprise Edition (J2EE)の参照実装と相互運用できます。

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

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

    ノート:

    WebLogic ServerにおけるCSIv2実装は、Java EE 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セキュリティ

WebLogic Serverでは、JASPICを使用してWebアプリケーションの認証構成プロバイダを構成し、そのWebアプリケーション用のデフォルトのWLS認証メカニズムのかわりにそれを使用するサポートが拡張されています。

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認証構成プロバイダは、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 Server Open Source Editionアプリケーション開発ガイド』のサーブレット・コンテナへの認証メカニズムの追加に関する項で説明しています。GlassFishサーバーの観点で記載されていますが、SAMを作成するためのヒントやSAM用のサンプルは役立ちます。

Java EE Security API

Oracle WebLogic Serverでは、移植可能な認証メカニズム(HttpAuthenticationMechanism、IdentityStoreなど)や、SecurityContextインタフェースを使用したプログラムによるセキュリティのためのアクセス・ポイントを定義するJava EE Security API (JSR 375)をサポートしています。WebLogic Serverでは、Webコンテナ内でこれらの認証メカニズムがサポートされ、サーブレットおよびEJBコンテナ内でSecurityContextインタフェースがサポートされています。

移植可能なプラグインの認証ストアおよびアイデンティティ・ストアのインタフェースでは、アプリケーションがその認証に使用する認証プロセスとアイデンティティ・ストアを標準的かつ移植可能な方法で制御できるため、標準的なコンテナ提供の実装に比べてメリットがあります。セキュリティ構成を外部で構成せずにアプリケーション内にバンドルすることで、アプリケーションのライフサイクルの管理を向上させることができます。特に、マイクロサービスがコンテナに分散されている環境においてはこれが有効です。

Java EE Security APIでは、グループ・プリンシパル名がデフォルトで同じ名前のロールにマップされている必要があります。WebLogic Serverでは、weblogic.xmlデプロイメント記述子のsecurity-role-assignment要素が、WebLogic Serverセキュリティ・レルムでセキュリティ・ロールと1つ以上のプリンシパルとの間のマッピングを宣言していない場合、ロール名がデフォルトのプリンシパルとして使用されます。

特別なロギング要件はありません。Java EE Security APIの実装によってトリガーされた監査イベントは、WebLogic監査プロバイダ(構成されている場合)によってログに記録されます。

Java EE Security API 1.0 (JSR 375)のプログラミング・モデルは、https://www.jcp.org/en/jsr/detail?id=375?id=375の仕様で定義されています。

WebLogic ServerでのJSR 375の使用の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJava EE Security APIの使用に関する項を参照してください。

次の各トピックで、Java EE Security APIの機能に関する追加情報を提供します:

認証メカニズム

WebLogic Serverでは、認証用に次のJSR 375プラグインSPIをサポートしています:

  • HttpAuthenticationMechanism (HAM) - このインタフェースは、Webアプリケーションの呼出し側を認証するために使用されます。アプリケーションは、独自のカスタムHttpAuthenticationMechanismを指定することも、コンテナにより提供された組込みメカニズムの1つを使用することもできます。WebLogic Serverでは、BASIC、FORMおよびカスタムFORM認証をサポートする3つの標準的な組込み認証メカニズムに加え、カスタムHAMもサポートしています。HttpAuthenticationMechanismインタフェースは、既存のサーブレットおよびJASPIC認証メカニズムのメリットを活用できるように設計されており、WebLogicサーバーでJASPICが有効になっている(デフォルト)ことが必要です。

  • IdentityStore - このインタフェースは、呼出し側の資格証明(ユーザー名やパスワードなど)を検証し、グループ・メンバーシップ情報を返すメソッドを定義します。アプリケーションは、独自のカスタムIdentityStoreを提供することも、WebLogic Serverの組込みのLDAPストアまたはデータベース・ストアを使用することもできます。

  • RememberMeIdentityStore - このインタフェースは、認証されたユーザーのアイデンティティを長期間記憶する必要がある場合に対処することを目的とした、IdentityStoreインタフェースのバリエーションです。これにより、呼出し側は、毎回プライマリ認証資格証明を提示しなくても、定期的にアプリケーションに戻ることができます。

これらのSPIインタフェースの実装は、CDI Beanです。そのため、アプリケーションは、アプリケーション固有の認証メカニズムをサポートする実装を提供することも、デプロイされたアプリケーションの一部であるBeanアーカイブにインタフェースを含めることによって、アプリケーション固有のアイデンティティ・ストアに基づいてユーザー資格証明を検証することもできます。WebLogic ServerでのCDIサポートの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のJava EEプラットフォームのContexts and Dependency Injectionの使用に関する項を参照してください。

コンテナは、HttpAuthenticationMechanismをサービスに組み込む役割を持ちます。IdentityStoreインタフェースは主にHttpAuthenticationMechanism実装での使用を意図したものですが、理論上は他のタイプの認証メカニズム(JASPIC ServerAuthModuleなど)でも使用できます。HttpAuthenticationMechanism実装でIdentityStoreを使用することは必須ではなく、どのような方法でもユーザーを認証できますが、IdentityStoreインタフェースが有用で便利なメカニズムです。

プログラムによるセキュリティ

Java EE Security API (JSR 375)仕様では、アプリケーション・コードが現在のセキュリティ・コンテキストを問い合せてそれとやり取りするために使用する、SecurityContext APIが定義されています。

SecurityContextインタフェースは、アプリケーションが呼出し側に関するセキュリティ情報にアクセスし、呼出し側を認証し、呼出し側を認可できるようにするメソッドを定義します。次のメソッドがあります:

  • getCallerPrincipal() - 呼出し側を表すプリンシパルを取得します。

  • getPrincipalsByType() - 特定のタイプのすべてのプリンシパルを取得します。

  • isCallerInRole() - 認証された呼出し側が指定の論理アプリケーション・ロールに含まれているかどうかをチェックします。

  • hasAccessToWebResource() - 呼出し側が指定のHTTPメソッドに指定されているWebリソースにアクセスできるかどうか(アプリケーションに構成されているセキュリティ制約により決定される)を判別します。

  • authenticate() - 呼出し側に関する認証プロセスを開始する必要があることをアプリケーションがコンテナに通知できるようにします。

getCallerPrincipal()、getPrincipalsByType()およびisCallerInRole()メソッドは、(Webサービスを含む) WebLogicサーブレットおよびEJBコンテナ内で使用可能です。

hasAccessToWebResource()およびauthenticate() APIは、(Webサービスを含む) WebLogicサーブレット・コンテナ内でのみサポートされています。