17 IDアサーション・プロバイダの構成
この章の内容は次のとおりです。
IDアサーション・プロバイダについて
-
WebLogic IDアサーション・プロバイダ
-
LDAP X509 IDアサーション・プロバイダ
-
ネゴシエーションIDアサーション・プロバイダ
-
SAML IDアサーション・プロバイダ(SAML 1.1用)
-
SAML 2.0 IDアサーション・プロバイダ
ノート:
WebLogic Serverには、認証とアイデンティティ・アサーションを組み合せて単一のプロバイダにしているOracle Identity Cloud Integratorプロバイダが組み込まれています。アイデンティティ・ストアがOracle Identity Cloud Serviceである場合、このプロバイダは、認証ユーザー、ユーザーのグループおよびユーザーのアプリケーション・ロールを使用してアイデンティティ(サブジェクト)をWebLogic Serverに対して確立します。「Oracle Identity Cloud Integratorプロバイダの構成」を参照してください。セキュリティ・レルムでは複数のIDアサーション・プロバイダを構成できますが、必須ではありません。IDアサーション・プロバイダでは複数のトークン・タイプをサポートできますが、一度にアクティブになるのはIDアサーション・プロバイダごとに1つのトークン・タイプだけです。WebLogic Server管理コンソールのプロバイダ固有の構成ページの「アクティブなタイプ」フィールドで、アクティブなトークン・タイプを定義します。WebLogic IDアサーション・プロバイダは、次を持つIDアサーションをサポートしています。
-
X.509証明書
-
CORBA Common Secure Interoperability version 2 (CSI v2)
CSI v2 IDアサーションを使用している場合、WebLogic Server管理コンソールの「プロバイダ固有」ページからアクセスできる「信頼性のあるクライアントのプリンシパル」フィールドで、クライアント・プリンシパルのリストを定義します。
-
weblogic-jwt-token
トークンこのトークン・タイプは、ドメイン内の他アプリケーションのREST呼出しでアイデンティティを伝播するために内部的に使用され、デフォルトで構成済です。
セキュリティ・レルムに複数のIDアサーション・プロバイダを構成した場合、すべてのIDアサーション・プロバイダで同じトークン・タイプをサポートできます。ただし、トークンは一度に1つのプロバイダのみに対してアクティブにできます。
WebLogic IDアサーション・プロバイダでは、ユーザー名マッパーを使用して、IDアサーション・プロバイダで認証されるトークンをセキュリティ・レルム内のユーザーにマップすることもできます。ユーザー名マッパーの構成の詳細は、「WebLogic資格証明マッピング・プロバイダの構成」を参照してください。
Webアプリケーションの認証タイプがCLIENT-CERT
に設定されている場合、WebLogic ServerのWebアプリケーション・コンテナは、リクエスト・ヘッダーおよびCookieからの値に対してIDアサーションを実行します。ヘッダー名またはCookie名が、構成されているIDアサーション・プロバイダのアクティブなトークン・タイプに一致していれば、値はプロバイダに渡されます。
「プロバイダ固有」ページの「Base64でのデコーディングが必要」の値は、リクエスト・ヘッダー値またはCookie値をIDアサーション・プロバイダへ送信する前に、Base64でデコードする必要があるかどうかを決定します。この設定はデフォルトでは後方互換性のために有効になっていますが、ほとんどのIDアサーション・プロバイダでは、このオプションは無効化されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびアイデンティティ・アサーション・プロバイダの構成に関する項を参照してください。
LDAP X509 IDアサーション・プロバイダの仕組み
LDAP X509 IDアサーション・プロバイダは、X509証明書を受け取り、その証明書に関連付けられたユーザーのLDAPオブジェクトをルックアップして、LDAPオブジェクトの証明書が提示された証明書と一致することを確認し、LDAPオブジェクトからユーザーの名前を取得します。
LDAP X509 IDアサーション・プロバイダは、以下のように機能します。
-
境界認証(つまり、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する)を使用するようにアプリケーションがセット・アップされます。
-
SSLハンドシェーク機能の一部として、アプリケーションは証明書を提示します。証明書のサブジェクトDNを使用して、LDAPサーバー内のそのユーザーを表すオブジェクトを特定できます。オブジェクトには、ユーザーの証明書と名前が含まれています。
-
LDAP X509 IDアサーション・プロバイダは、サブジェクトDNの証明書を使用して、LDAP検索を構築し、LDAPサーバー内のユーザーのLDAPオブジェクトを見つけます。そのオブジェクトから証明書を取得し、それが自らの保持する証明書と一致していることを確認し、ユーザーの名前を取得します。
-
ユーザー名は、セキュリティ・レルムで構成されている認証プロバイダに渡されます。認証プロバイダは、ユーザーが存在していることを確認し、そのユーザーが属するグループを特定します。
LDAP X509 IDアサーション・プロバイダの構成: 主なステップ
LDAP X509 IDアサーション・プロバイダを使用するには:
ネゴシエーションIDアサーション・プロバイダの構成
ネゴシエーションIDアサーション・プロバイダは、WebLogicセキュリティ・フレームワークに定義されているようにセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の実装であり、クライアントをそのSPNEGOトークンに基づいて認証するのに必要なロジックを提供します。
ネゴシエーションIDアサーション・プロバイダのセキュリティ・レルムへの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。ネゴシエーションIDアサーション・プロバイダをMicrosoftクライアントSSOと一緒に使用する方法については、Microsoftのクライアントに対するシングル・サインオンの構成を参照してください。
表17-1 ネゴシエートIDアサーション・プロバイダの属性
属性 | 説明 |
---|---|
フォームベースのネゴシエーションを有効化 |
WebアプリケーションがFORM認証を行うように構成されている場合にネゴシエーションIDアサーション・プロバイダとサーブレット・フィルタでネゴシエーションを行うかどうかを指定します。 |
アクティブなタイプ |
このネゴシエーションIDアサーション・プロバイダが認証に使用するトークン・タイプ。使用可能なトークン・タイプは、 同じセキュリティ・レルム内に構成されている他のIDアサーション・プロバイダでこの属性がX509に設定されていないことを確認してください。 |
SAML 1.1用のSAML IDアサーション・プロバイダの構成
WebLogic Serverには、SAML 1.1.用のSAML IDアサーション・プロバイダ・バージョン2が組み込まれています。構成オプションが大幅に拡張されているため、新しいデプロイメントではこれを使用することをお薦めします。セキュリティ・レルムに複数のSAML IDアサーション・プロバイダを含めることはできません。また、セキュリティ・レルムにSAML IDアサーション・プロバイダとSAML資格証明マッピング・プロバイダの両方が含まれる場合は、両方のバージョンが同じである必要があります。
SAML IDアサーション・プロバイダをSAMLシングル・サインオン構成で使用する方法は、SAMLを使用するWebブラウザとHTTPクライアントでのシングル・サインオンの構成を参照してください。WebLogic ServerでのSAMLのサポートの概要については、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)を参照してください。
次の各項では、SAML 1.1向けのSAMLアイデンティティ・アサーション・プロバイダの構成方法について説明します。
アサーティング・パーティ・レジストリ
WebLogic ServerをSAMLセキュリティ・アサーションのコンシューマとして機能するように構成する場合には、SAMLアサーションが受け付けられるパーティを登録する必要があります。各SAMLアサーティング・パーティに対して、使用するSAMLプロファイル、そのアサーティング・パーティの詳細、そのアサーティング・パーティで受信されるアサーションで予想される属性を指定できます。次のトピックを参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1アサーティング・パーティの構成
証明書レジストリ
SAML IDアサーション・プロバイダは、信頼性のある証明書のレジストリを保持します。証明書を受け取ると、このレジストリ内の証明書と照らし合わせて検証します。各アサーティング・パーティでは、そのパートナから受け取る以下の証明書がこのレジストリに格納されます。
-
このアサーティング・パーティから受け取ったアサーションの署名を検証するために使用する証明書。
-
このアサーティング・パーティからのSAMLプロトコル要素の署名を検証するために使用する証明書。この証明書は、ブラウザ/POSTプロファイル用に設定する必要があります。
-
アサーティング・パーティの信頼性を検証するために使用するTLS/SSL証明書。そのパートナが、SSL接続を使用してアサーション検索サービス(ARS)からアーティファクトを取得する際に使用します。
WebLogic Server管理コンソールを使用して、信頼性のある証明書を証明書レジストリに追加できます。
- 管理コンソールで、「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」ページに移動します。
- SAML IDアサーション・プロバイダの名前をクリックし、「管理」>「証明書」ページを開きます。
「管理」>「証明書」ページで、レジストリの証明書を追加、削除、および表示します。
SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成
-
署名をチェックし、パートナ用に構成されたデータに基づいて信頼性を検証することによって、SAML 2.0アサーションを検証します。次に、SAML 2.0 IDアサーション・プロバイダはアサーションに含まれているID情報を抽出し、それをセキュリティ・レルム内のローカル・サブジェクトにマップします。
-
必要に応じて、アサーションに含まれている属性情報を抽出します。SAML認証プロバイダがセキュリティ・レルム内に構成されている場合は、この属性情報を使用して、マップしたサブジェクトが属すローカル・グループを特定することも可能です。(「SAML認証プロバイダの構成」を参照してください。)
-
必要に応じて、アサーションに指定された有効期間や再利用の設定が有効かどうかを検証し、期限が切れている場合や再利用が不可能な場合はアサーションを拒否します。
SAML 2.0 IDアサーション・プロバイダの構成は、SAML2IdentityAsserterMBean
の属性を設定することで制御できます。SAML2IdentityAsserterMBean
にアクセスするには、WebLogic Scripting Tool (WLST)を使用するか、WebLogic Server管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」ページを使用して、SAML2IdentityAsserter
を作成または選択します。これらの属性の詳細は、Oracle WebLogic Server MBeanリファレンスのSAML2IdentityAsserterMBean
を参照してください。
SAML 2.0 IDアサーション・プロバイダをSAMLシングル・サインオン構成で使用する方法は、SAMLを使用するWebブラウザとHTTPクライアントでのシングル・サインオンの構成を参照してください。WebLogic ServerでのSAMLのサポートの概要については、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)を参照してください。Webサービス・セキュリティでのSAML 2.0 IDアサーション・プロバイダの使用については、『Oracle WebLogic Server WebLogic Webサービスの保護』のSecurity Assertion Markup Language (SAML)トークンのIDとしての使用に関する項を参照してください。
アイデンティティ・プロバイダの構成方法は、アイデンティティ・プロバイダ・パートナを参照してください。
IDプロバイダ・パートナ
WebLogic Serverをサービス・プロバイダとして機能するように構成する場合は、SAML 2.0アサーションの送信と検証を行うIDプロバイダ・パートナを作成して構成します。IDプロバイダ・パートナを構成するには、パートナに関する以下のような基本情報を指定する必要があります。
-
パートナ名と一般的な説明
-
このパートナで使用する名前マッパー・クラス
-
このパートナから受け取るアサーションに含まれている属性文を消費するかどうか
-
このパートナから受け取るアサーションに含まれているIDを仮想ユーザーにマップするかどうか
-
このパートナから受け取った署名付きアサーションを検証するために使用する証明書
ここで指定する情報は、パートナをWebシングル・サインオン用に構成するかWebサービス用に構成するかによって変わってきます。Webシングル・サインオンIDプロバイダ・パートナの場合も、パートナのメタデータ・ファイルをインポートし、そのパートナに関する以下のような基本情報を追加で指定する必要があります。
-
リダイレクトURI。未認証のユーザーによって呼び出された場合に、そのIDプロバイダ・パートナで認証するためにユーザー・リクエストをリダイレクトするURLです。
-
このパートナから受け取るSAMLアーティファクト・リクエストに署名が必要かどうか。
-
このパートナにSAMLアーティファクトを配信する方法。
Webシングル・サインオンIDプロバイダ・パートナの構成については、以下を参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオンIDプロバイダ・パートナの作成に関する項
WebサービスIDプロバイダ・パートナの構成ではメタデータ・ファイルは使用しませんが、そのパートナに関する以下の情報を指定する必要があります。
-
発行者URI。SAMLフェデレーション内で、このIDプロバイダ・パートナを一意に識別するための文字列です。
-
オーディエンスURI。このパートナから受け取るアサーションに含めるオーディエンス制約を指定します。
WebLogic Serverでは、Webサービス・ランタイムがパートナの検索に使用するパートナ検索文字列を保持する必要もあるため、オーディエンスURI属性がオーバーロードされています。「Webサービス・パートナに必要なパートナ検索文字列」を参照してください。
-
デフォルトの名前マッパーをオーバーライドするカスタム名前マッパー・クラス。このマッパー・クラスは、このパートナでのみ使用します。
Webサービス用のサービス・プロバイダ・パートナの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webサービス・サービス・プロバイダ・パートナの作成に関する項を参照してください。
次のトピックでは、IDプロバイダ・パートナの属性を構成する方法について説明しています。
Webサービス・パートナに必要なパートナ・ルックアップ文字列
WebサービスIDプロバイダ・パートナの場合は、オーディエンスURIも構成します。WebLogic Serverでは、以下のまったく異なる2つの用途に使用できるよう、オーディエンスURI属性がオーバーロードされています。
-
OASIS SAML 2.0仕様に従って、ターゲットURLからなるオーディエンス制約を指定します。
-
パートナ・ルックアップ文字列を保持します。WebLogic Serverでは、実行時にこのルックアップ文字列を使用して、SAML 2.0アサーションの検証に使用するIDプロバイダ・パートナを見つけます。
パートナ・ルックアップ文字列には、パートナ・ルックアップに使用するエンドポイントURLを指定します。必要に応じて、このIDプロバイダ・パートナから受け取るアサーションに含める必要のあるオーディエンスURI制約として使用することもできます。
ノート:
パートナ・ルックアップ文字列は、Webサービス・ランタイムが実行時にIDプロバイダ・パートナを見つけられるように構成する必要があります。
ルックアップ文字列の構文
パートナ・ルックアップ文字列の構文は次のとおりです。
[target:char:]<endpoint-url>
この構文で、target:
char
:
はパートナ・ルックアップ文字列を指定する接頭辞、charはハイフン(-
)、プラス記号(+
)、またはアスタリスク(*
)のいずれか1つの特殊文字を表します。表17-2に示すように、この接頭辞によってパートナ・ルックアップの実行方法が決まります。
ノート:
サービス・プロバイダとして機能するように構成されたWebLogic Serverインスタンスでは常に、SAML 2.0 IDアサーション・プロバイダに渡すエンドポイントURLからtransport、host、portの部分が除去されます。したがって、IDプロバイダ・パートナ用のルックアップ文字列として指定するすべてのエンドポイントURLには、hostとportより後ろの部分のみを含める必要があります。たとえば、target:*:/myserver/xxx
のようにします。
これにより、サービス・プロバイダ・サイトを構成する際に、あるWebサービスをホストするドメイン内の複数のマシンで使用するトランスポート・プロトコル(たとえばHTTPかHTTPSか)、ホスト名、IPアドレス、ポート情報が違っていても、そのWebサービスのすべてのアサーションを単一のIDプロバイダ・パートナで検証することが可能になります。
表17-2 IDプロバイダ・パートナ・ルックアップ文字列の構文
ルックアップ文字列 | 説明 |
---|---|
|
URL この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、このIDプロバイダ・パートナのオーディエンスURIとしては追加されません。 |
|
URL ノート: プラス記号( |
|
文字列の先頭のパターンがURL 先頭の文字列パターンに一致するIDプロバイダ・パートナが複数見つかった場合は、一致した文字列パターンが最も長いパートナが選択されます。 この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、このIDプロバイダ・パートナのオーディエンスURIとしては追加されません。 |
ノート:
実行時にIDプロバイダ・パートナが見つかるようにするため、1つのパートナに1つ以上のパートナ・ルックアップ文字列を構成する必要があります。パートナが見つからない場合、そのパートナのアサーションは検証できません。
target検索接頭辞を使用せずにエンドポイントURLを構成すると、従来のオーディエンスURIとして扱われるため、IDプロバイダ・パートナから受け取るアサーションに必ずオーディエンスURIを含める必要があります(これにより、このパートナに構成されている既存のオーディエンスURIとの後方互換性も確保できます。)
デフォルト・パートナの指定
デフォルトのIDプロバイダ・パートナ・エントリを指定したい場合は、1つまたは複数のデフォルト・パートナのオーディエンスURIエントリに、すべてのターゲットに有効なワイルドカード一致を含めることができます。たとえば、target:*:/
のようにします。
パートナ証明書の管理
SAML 2.0 IDアサーション・プロバイダは、構成されているパートナの信頼性のある証明書を管理します。パートナ・メッセージの交換中に受け取った証明書は、そのパートナ用に保持している証明書と照合されます。パートナの証明書は、以下の用途に使用します。
-
サービス・プロバイダ・サイトで署名付きアサーションまたはSAMLアーティファクト・リクエストを受け取ったときに信頼性を検証するため
-
アーティファクト解決サービス(ARS)からSSL接続経由でSAMLアーティファクトを取得しているIDプロバイダ・パートナの信頼性を検証するため
構成されている各IDプロバイダ・パートナから取得する証明書としては、以下が必要になります。
-
パートナから受け取った署名付きSAMLドキュメント(アサーション、アーティファクト・リクエストなど)を検証するための証明書
Webシングル・サインオンで署名付きSAMLドキュメントを検証するために使用する証明書は、IDプロバイダ・パートナから受け取るメタデータ・ファイルに含まれています。WebサービスIDプロバイダ・パートナを構成する場合は、この証明書をパートナから取得し、このパートナの構成にインポートします。この操作は、WebLogic Server管理コンソールのパートナ管理ページにある「アサーション署名用証明書」タブで行います。
-
SAMLアーティファクトを取得するために、ローカル・サイトのSSLバインディングに対してパートナが確立した接続を検証するためのトランスポート層セキュリティ(TLS)クライアント証明書(Webシングル・サインオンでのみ使用)
Webシングル・サインオンIDプロバイダ・パートナを構成する場合は、TLSクライアント証明書をパートナから直接取得する必要があります。この証明書は、自動的にメタデータ・ファイルに含まれるものではありません。この証明書をパートナの構成データにインポートするには、WebLogic Server管理コンソールのパートナ管理ページにある「トランスポート層クライアント証明書」タブを使用します。
IDプロバイダ・パートナの属性を構成するためのJavaインタフェース
Webサービス・パートナの属性は、com.bea.security.saml2.providers.registry.Partner
Javaインタフェースを使用して操作できます。
サーブレットに対するIDアサーションの順序付け
-
X.509がデフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つである場合は、X.509デジタル証明書(クライアントとWebサーバーの間での双方向SSLを備えた、クライアントまたはプロキシ・プラグインへの双方向SSLを示します)。
-
WL-Proxy-Client-<
TOKEN
>
という形式の名前を持つヘッダー。<
TOKEN
>
は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。ノート:
この方法は非推奨で、後方互換性のためだけに使用する必要があります。
-
<
TOKEN
>
という形式の名前を持つヘッダー。<
TOKEN
>
は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。 -
<
TOKEN
>
という形式の名前を持つCookie。<
TOKEN
>
は、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダに対して構成されているアクティブなトークン・タイプの1つです。
たとえば、デフォルト・セキュリティ・レルムのIDアサーション・プロバイダがアクティブなトークン・タイプとしてFOO
およびBAR
というトークンを持つように構成されている場合(次の例では、HTTPリクエストにはIDアサーションに関連するものはアクティブなトークン・タイプ以外、何も含まれていないものとします)、IDアサーションは次のように実行されます。
-
FOO
ヘッダーを持つリクエストが双方向SSL接続を使用して受信される場合、X.509がIDアサーションに使用されます。 -
FOO
ヘッダーを持ち、WL-Proxy-Client-BAR
ヘッダーを持つリクエストが受信される場合、BAR
トークンがIDアサーションに使用されます。 -
FOO
ヘッダーを持ち、BAR
Cookieを持つリクエストが受信される場合、FOO
トークンがIDアサーションに使用されます。
同じレベルの複数のトークン間の順序付けは定義されていません。そのため、次のようになります。
-
FOO
ヘッダーを持ち、BAR
ヘッダーを持つリクエストが受信される場合、FOO
トークンまたはBAR
トークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。 -
FOO
Cookieを持ち、BAR
Cookieを持つリクエストが受信される場合、FOO
トークンまたはBAR
トークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。
サーバー・キャッシュのIDアサーション・パフォーマンスの構成
<run-as>
タグのあるサーブレットおよびEJBメソッドや、HTTPSessionでIDアサーションが使用されるがキャッシュはされないような他の状況(XMLドキュメントの署名や暗号化など)におけるパフォーマンスが大幅に向上します。
IDアサーション・プロバイダが使用するキャッシュ・サービスを最適化するには、「IDアサーション・キャッシュ・サービスの最適化」を参照してください。
ノート:
キャッシングは、セマンティクスに違反することがあります。
IDアサーションのパフォーマンスが上がるにつれて、IDアサーション・プロバイダは構成されている認証プロバイダの変化に反応しなくなります。たとえば、ユーザーのグループの変更は、サブジェクトがキャッシュからフラッシュされて再作成されるまで反映されなくなります。このコマンドライン引数の値を小さく指定すると、認証変更の反応はよくなりますが、パフォーマンスは低下します。
IDアサーション・キャッシュ・サービスの最適化
IDアサーション・プロバイダのパフォーマンスを向上させるために、IDアサーション・キャッシュ・サービスの設定を適宜変更できます。
IDアサーション・キャッシュ・サービスのパフォーマンスを最適化するには、WebLogic Scripting Tool (WLST)またはWebLogic Server管理コンソール(「構成」→「一般」→セキュリティ・レルムの「詳細」ページ)を使用して、セキュリティ・レルムに対して次のRealmMBean
属性を設定します:
IdentityAssertionCacheEnabled
— この属性を使用して、IDアサーション・プロバイダのキャッシュ・サービスを有効にするかどうかを指定します。デフォルトでは、この属性はtrueに設定されており、キャッシュは有効になっています。-
IdentityAssertionCacheTTL
— IDアサーション・キャッシュ内でサブジェクトが存続できる最大秒数を設定することにより、キャッシュ内のアイテムの存続時間を指定します。この存続時間(TTL)値は、IDアサーション・キャッシュが有効になっている場合にのみ設定できます。この値のデフォルトは300(秒)です。 -
IdentityAssertionDoNotCacheContextElements
— IDアサーション・キャッシュに格納しないContextElementの名前を指定します。これらの要素はリクエストのContextHandlerに存在するためです。この値は、IdentityAssertionCacheEnabled
がtrueに設定されている場合にのみ使用されます。この値のデフォルトは、空文字列リストです。
IDアサーション・キャッシュ内のアイテムの存続時間(TTL)値は、-Dweblogic.security.identityAssertionTTL
コマンドライン引数を使用してオーバーライドできます。コマンド・ライン引数に指定できる値は次のとおりです。
- 0より小さい値 — キャッシュを無効化します。
- 0 — キャッシュは有効であり、サーバーが実行中であるかぎりキャッシュ内のアイデンティティがタイムアウトになることはありません。キャッシュされたエントリのユーザー・データベースが変更された場合は、サーバーがエントリを取得するために必ずサーバーの再起動が必要になります。
- 0より大きい値 — キャッシュは有効であり、キャッシュは指定された秒数でリセットされます。
IDアサーションのパフォーマンスを向上させるには、このコマンド・ライン引数により大きな値を指定します。
ノート:
RealmMBean
属性IdentityAssertionCacheTTL
とコマンドライン引数-Dweblogic.security.identityAssertionTTL
の両方を使用して存続時間(TTL)値を設定した場合は、コマンドライン引数のほうがMBean属性より優先されます。
アイデンティティ・ストアで未定義のユーザーの認証
WebLogic IDアサーション・プロバイダは、デフォルトでは仮想ユーザーを認証するように構成されていません。ただし、このプロバイダの構成をカスタマイズすることにより、WebLogicドメインでこの機能を有効化できます。
ノート:
仮想ユーザー認証は、双方向SSLに対応するように構成され、CLIENT-CERT
認証を使用するリスニング・サーブレットを備えたネットワーク・ポートのみでサポートされます。
仮想ユーザー認証は次のようなトポロジではサポートされません。
-
SSLがフロントエンド・プロキシで終了
-
SSLが有効になっていないWebLogic Serverインスタンスへのリクエストの転送
次の項で、仮想ユーザー認証の仕組みを説明して、WebLogicドメインで構成するステップを示します。
WebLogicドメインでの仮想ユーザー認証の仕組み
仮想ユーザー認証は、標準のWeblogic Serverセキュリティ・プロバイダJAAS認証プロセスに従って行われます。次のように、仮想ユーザーを許可するようにWebLogic IDアサーション・プロバイダを構成すると、セキュリティ・レルムのアイデンティティ・ストアに定義されていないユーザーをドメインで認証できます。
-
ユーザーが、WebLogicドメインでホストされるリソースに対するリクエストを発行すると、ユーザーとWebLogic Server間の双方向SSL接続が確立されます。
-
このユーザーを認証するためにWebLogic IDアサーション・プロバイダが呼び出されます。このプロバイダは仮想ユーザーに対応するため、X.509クライアント証明書がX.509タイプのトークンとしてプロバイダに渡されます。
-
WebLogic IDアサーション・プロバイダは、構成済のユーザー名マッパーを呼び出して、次の操作を実行します。
-
X.509証明書に含まれる属性からデータを抽出します。
-
必要な証明書属性データをサブジェクトのプリンシパルと資格証明にマップします。
-
仮想ユーザーのコールバック・ハンドラを仮想ユーザー認証プロバイダのログイン・モジュールに戻します。
仮想ユーザーを許可するようにWebLogic IDアサーション・プロバイダが構成され、構成済ユーザー名マッパーで所定の証明書の仮想ユーザーが許可されると、仮想ユーザーが
allowed
とみなされます。 -
-
ログイン・モジュールは、仮想ユーザー・コールバック・ハンドラを使用して、認証済サブジェクトを作成します。これは、X.509証明書の属性から導出されたプリンシパルで構成されます。証明書から導出されたプリンシパルにはユーザー名が含まれます。使用されるユーザー名マッパーによって異なりますが、グループ名、プライベート資格証明、パブリック資格証明、その他のプリンシパルが含まれることもあります。
-
WebLogicセキュリティ・フレームワークは、他の認証プロバイダよりも先に仮想ユーザー認証プロバイダを呼び出します。JAAS制御フラグがSUFFICIENTに設定されているため、ユーザーがWebLogicドメインで認証されます。ユーザーの検証またはサブジェクトのその他のコンポーネントの取得に、アイデンティティ・ストア(LDAPサーバーなど)が使用されることはありません。
双方向SSLの構成と証明書のセキュアな管理
仮想ユーザーをWebLogicドメインで認証できるようにWebLogicセキュリティ・フレームワークを構成する前に、ドメインのSSL構成を最適化し、WebLogic Serverの証明書検証機能を利用することを強くお薦めします。次のステップを実行して、クライアント証明書が問題なく信頼できることと検証されていることを確認します。
- 双方向SSL (クライアント認証を含むSSL)を構成します。双方向SSLでは、サーバーがクライアントに証明書を提示し、クライアントがサーバーに証明書を提示します。
- SSL接続で有効な最小のSSLバージョンを制限するようにSSLを構成します。「SSL/TLSプロトコル・バージョンの指定」を参照してください。
- SSL証明書の検証がドメインで適切に構成されていることを確認します。「SSL証明書の検証」を参照してください。
- X.509証明書失効(CR)チェックを構成します。X.509証明書失効チェックによって、SSL証明書パス検証プロセスの一部として、証明書の失効ステータスがチェックされます。CRチェックによって、受け取った証明書が発行元の認証局によって失効されていないことが保証され、証明書の使用におけるセキュリティが向上します。X.509証明書失効チェックを参照してください。
WebLogic IDアサーション・プロバイダ(DefaultIdentityAsserter)のカスタマイズ
WebLogic IDアサーション・プロバイダ(DefaultIdentityAsserter)はWebLogicドメインでデフォルトで構成されています。仮想ユーザーの認証を有効にするには、WebLogicドメインでこのプロバイダのデフォルト・インスタンスをカスタマイズします。または、このプロバイダの別のインスタンスを作成してそれをカスタマイズします。
仮想ユーザー認証を有効にするようにWebLogic IDアサーション・プロバイダを構成するには、次のステップを実行します。
これらのステップの操作方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「アイデンティティ・ストアに定義されていないユーザーの認証」を参照してください。
WebLogic Serverでは、weblogic.security.providers.authentication.X509SubjectComponentMapper
インタフェースの実装であるカスタム・ユーザー名マッパーも使用できます。X.509証明書の他の属性(グループ・プリンシパル、プライベート資格証明またはパブリック資格証明など)をマップする必要がある場合は、カスタム・ユーザー名マッパーの使用をお薦めします。
仮想ユーザー認証プロバイダの構成
仮想ユーザー認証プロバイダはデフォルトではWebLogicドメインで使用できません。このプロバイダの構成方法の詳細は、仮想ユーザー認証プロバイダの構成を参照してください。このプロバイダをセキュリティ・レルムに追加した後で、次の操作を実行します。
- 仮想ユーザー認証プロバイダが最初になるように認証プロバイダの順序を変更します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダの順番の変更に関する項を参照してください。
- 仮想ユーザー認証プロバイダのJAAS制御フラグを
SUFFICIENT
に設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJAAS制御フラグの設定に関する項を参照してください。
WLSTを使用する仮想ユーザー認証の構成
この項では、WebLogicドメインでの仮想ユーザー認証の構成例を示します。例17-1は、次のことを示しています:
-
WebLogic Serverインスタンスに接続します。
-
仮想ユーザー認証プロバイダのインスタンスを作成します。
-
セキュリティ・レルムの認証プロバイダの中で仮想ユーザー認証プロバイダが最初になるように順序を設定します。
-
WebLogic IDアサーション・プロバイダ(DefaultIdentityAsserter)で仮想ユーザーを有効にします。
-
WebLogic Serverによって提供されるデフォルト・ユーザー名マッパーを有効にします。
-
変更内容を保存してセキュリティ・レルムでアクティブ化します。
例17-1 仮想ユーザー認証プロバイダの構成と仮想ユーザーの有効化
connect('','','t3://host:port') Please enter your username : Please enter your password : ... edit() startEdit() print 1 cd('/SecurityConfiguration/'+domainName+'/Realms/myrealm') print 2 auth=cmo.lookupAuthenticationProvider('VirtualUserAtnProvider') print 3 if auth == None: print 4 auth = cmo.createAuthenticationProvider('VirtualUserAtnProvider','weblogic.security.providers.authentication.VirtualUserAuthenticator') print auth set('AuthenticationProviders',jarray.array([ObjectName('Security:Name=myrealmVirtualUserAtnProvider'),ObjectName('Security:Name=myrealmDefaultAuthenticator'),ObjectName('Security:Name=myrealmDefaultIdentityAsserter')],ObjectName)) print 5 cd('AuthenticationProviders/DefaultIdentityAsserter') set('VirtualUserAllowed','true') print( "VirtualUserAllowed set to true" ) set('UseDefaultUserNameMapper','true') print( "UseDefaultUserNameMapper set to true" ) save() activate()
ユーザー名マッパーの構成
-
WebブラウザまたはJavaクライアントのデジタル証明書とWebLogic Serverセキュリティ・レルムのユーザー。
-
X.509証明書に含まれる属性と、セキュリティ・レルムのアイデンティティ・ストアに定義されていないユーザーのサブジェクトのプリンシパルと資格証明(「アイデンティティ・ストアで未定義のユーザーの認証」を参照)。
ユーザー名マッパーは、weblogic.security.providers.authentication.UserNameMapper
インタフェースの実装でなければなりません。このインタフェースは、必要に応じた方式に従って、トークンをWebLogic Serverのユーザー名にマップします。デフォルトでは、WebLogic Serverはweblogic.security.providers.authentication.UserNameMapper
インタフェースのデフォルトの実装が提供されます。また、「カスタム・ユーザー名マッパーの構成」で説明しているように、独自の実装を作成することもできます。
WebLogic IDアサーション・プロバイダは、以下のIDアサーション・トークン・タイプについて、ユーザー名マッパーを呼び出します。
-
SSLハンドシェークを通じて渡されたX.509デジタル証明書
-
CSIv2を通じて渡されたX.509デジタル証明書
-
CSIv2を通じて渡されたX.501識別名
デフォルトのユーザー名マッパーは、デジタル証明書または識別名のサブジェクトDNを使用して、WebLogic Serverセキュリティ・レルムの適切なユーザーにマッピングします。たとえば、サブジェクトDNの電子メール属性(smith@example.com
)にあるユーザーを、WebLogic Serverセキュリティ・レルムのユーザー(smith
)にマッピングするように、ユーザー名マッパーを構成できます。この情報を定義するには、WebLogic IDアサーション・プロバイダの「デフォルト・ユーザー名マッパーの属性の種類」と「デフォルト・ユーザー名マッパーの属性のデリミタ」を使用します。
-
「デフォルト・ユーザー名マッパーの属性の種類」 - ユーザー名の算出に使用されるデジタル証明書のサブジェクト識別名(DN)。有効な値は、
C
、CN
、E
、L
、O
、OU
、S
、およびSTREET
です。デフォルトの属性タイプはE
です。 -
デフォルト・ユーザー名マッパーの属性のデリミタ - ユーザー名を終了させる記号。ユーザー名マッパーは、この値の左側のすべてを使用してユーザー名を算出します。デフォルトの区切り記号は
@
です。たとえば、電子メール・アドレスからユーザー名を抽出するとき、ユーザー名マッパーは、電子メール・アドレスの@記号の前のすべての文字を使用します。したがって、ユーザー名マッパーでサブジェクトDNの別の属性(たとえば、共通名またはCN)をマップしたい場合は、別のデリミタを指定することをお薦めします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー名マッパーの構成に関する項を参照してください。
カスタム・ユーザー名マッパーの構成
-
トークンをWebLogicユーザーにマップするカスタム・ユーザー名マッパーは、
weblogic.security.providers.authentication.UserNameMapper
インタフェースの実装でなければなりません。 -
仮想ユーザー(セキュリティ・レルムのアイデンティティ・ストアに定義されていないユーザー)の認証に使用されるサブジェクト・プリンシパルにX.509トークンをマップするカスタム・ユーザー名マッパーは、
weblogic.security.providers.authentication.X509SubjectComponentMapper
インタフェースの実装でなければなりません。X.509証明書の他の属性(グループ・プリンシパル、プライベート資格証明またはパブリック資格証明など)をマップする必要がある場合は、カスタム・ユーザー名マッパーの使用をお薦めします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。