| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12.2.1 12c (12.2.1) E70000-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12.2.1 12c (12.2.1) E70000-01 |
|
前 |
次 |
境界認証を使用する場合、IDアサーション・プロバイダを使用する必要があります。この章では、WebLogic Serverに含まれるIDアサーション・プロバイダの構成方法について説明します。
この章の内容は次のとおりです。
境界認証では、WebLogic Serverの外部にあるシステムがトークンを通じて信頼を確立します(これは単純認証とは対照的です。単純認証では、WebLogic Serverがユーザー名とパスワードを通じて信頼を確立します)。IDアサーション・プロバイダは、トークンを検証し、そのトークンの妥当性と信頼性を確立するために必要なアクションを実行します。各IDアサーション・プロバイダは、1つまたは複数のトークン・フォーマットをサポートします。
WebLogic Serverには、以下の新しいIDアサーション・プロバイダが組み込まれています。
WebLogic IDアサーション・プロバイダ
LDAP X509 IDアサーション・プロバイダ
ネゴシエーションIDアサーション・プロバイダ
SAML IDアサーション・プロバイダ(SAML 1.1用)
SAML 2.0 IDアサーション・プロバイダ
セキュリティ・レルムでは複数の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管理コンソール・オンライン・ヘルプの認証および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サーバーを使用するLDAP認証プロバイダも構成する必要があります。認証プロバイダは、ユーザーが存在していることを確認し、そのユーザーが属するグループを特定します。両方のプロバイダが、同じLDAPサーバーと通信できるように適切に構成されていることを確認してください。
LDAP X509 IDアサーション・プロバイダを使用するには:
ユーザーの証明書を取得し、それらをLDAPサーバーに置きます。第29章「キーストアの構成」を参照してください。
証明書のサブジェクトDNと、LDAPサーバー内におけるそのユーザーのオブジェクトの場所の間には、相関性が必要です。ユーザーのLDAPオブジェクトには、サブジェクトで使用される証明書およびユーザー名の構成情報も含まれている必要があります。
セキュリティ・レルムで、LDAP X509 IDアサーション・プロバイダを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。
WebLogic Server管理コンソールで、証明書のサブジェクトDNに指定されたLDAPディレクトリ内でユーザーのLDAPオブジェクトを見つけるようにLDAP X509 IDアサーション・プロバイダを構成します。
LDAPサーバーを検索して、ユーザーのLDAPオブジェクトを特定するようにLDAP X509 IDアサーション・プロバイダを構成します。これには、以下のデータが必要になります。
検索を開始するベースLDAP DN。LDAP X509 IDアサーション・プロバイダの「証明書マッピング」オプションは、そのIDアサーション・プロバイダが証明書のサブジェクトDNからベースLDAP DNを構築する方法を示します。LDAPオブジェクトには、証明書を保持する属性が含まれている必要があります。
定義されたオプションのセットに一致するLDAPオブジェクトのみを返す検索フィルタ。フィルタによってLDAP検索が制限されます。証明書のサブジェクトDNから検索フィルタを構築するように、ユーザー・フィルタ検索を構成します。
ベースLDAP DNを検索するLDAPディレクトリ内の場所。LDAP X509 IDアサーション・プロバイダは、再帰的に検索します(1レベル下)。この値は、証明書のサブジェクトDN内の値と一致する必要があります。
LDAP X509 IDアサーション・プロバイダの「証明書属性」属性を構成して、ユーザーのLDAPオブジェクトがどのように証明書を保持するかを指定します。LDAPオブジェクトには、証明書を保持する属性が含まれている必要があります。
LDAP X509 IDアサーション・プロバイダの「ユーザー名属性」属性を構成して、サブジェクトDNに表示されるユーザー名を保持するLDAPオブジェクトの属性を指定します。
LDAP X509 IDアサーション・プロバイダのLDAPサーバー接続を構成します。LDAPサーバーの情報は、このセキュリティ・レルムで構成されているLDAP認証プロバイダに対して定義されている情報と同じでなければなりません。
LDAP X509 IDアサーション・プロバイダと共に使用するLDAP認証プロバイダを構成します。LDAPサーバーの情報は、ステップ7で構成されたLDAP X509 IDアサーション・プロバイダに対して定義されている情報と同じにします。第13章「LDAP認証プロバイダの構成」を参照してください。
ネゴシエーションIDアサーション・プロバイダを使用すると、Microsoft社製のクライアントでシングル・サインオン(SSO)を利用できます。このIDアサーション・プロバイダでは、Simple and Protected Negotiate (SPNEGO)のトークンをデコードしてKerberosのトークンを取得し、そのKerberosトークンを検証した後でWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。
ネゴシエーションIDアサーション・プロバイダは、WebLogicセキュリティ・フレームワークに定義されているようにセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の実装であり、クライアントをそのSPNEGOトークンに基づいて認証するのに必要なロジックを提供します。
ネゴシエーションIDアサーション・プロバイダのセキュリティ・レルムへの追加については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。ネゴシエーションIDアサーション・プロバイダをMicrosoftクライアントSSOと一緒に使用する方法については、第20章「Microsoftのクライアントに対するシングル・サインオンの構成」を参照してください。
表18-1 ネゴシエートIDアサーション・プロバイダの属性
| 属性 | 説明 |
|---|---|
|
フォームベースのネゴシエーションを有効化 |
WebアプリケーションがFORM認証を行うように構成されている場合にネゴシエーションIDアサーション・プロバイダとサーブレット・フィルタでネゴシエーションを行うかどうかを指定します。 |
|
アクティブなタイプ |
このネゴシエーションIDアサーション・プロバイダが認証に使用するトークン・タイプ。使用可能なトークン・タイプは、 同じセキュリティ・レルム内に構成されている他のIDアサーション・プロバイダでこの属性がX509に設定されていないことを確認してください。 |
SAML IDアサーション・プロバイダは、SAML 1.1セキュリティ・アサーションのコンシューマとして機能します。WebLogic Serverは、このプロバイダを使用することで、シングル・サインオンにSAML 1.1を使用するための宛先サイトとして機能します。SAML IDアサーション・プロバイダは、署名をチェックし、保持する証明書レジストリ内の証明書の信頼性を検証することによって、SAML 1.1アサーションを検証します。信頼されていれば、アサーションに含まれるAuthenticationStatementに基づいてIDがアサートされます。また、SAML IDアサーション・プロバイダは、アサーションが以前に使用されていないことを確認します。SAMLアサーション・コンシューマ・サービスをサーバー・インスタンスにデプロイする場合は、SAML IDアサーション・プロバイダが構成されていなければなりません。
このリリースのWebLogic Serverには、SAML 1.1用のSAML IDアサーション・プロバイダが2つ含まれています。SAML IDアサーション・プロバイダ・バージョン2では構成オプションが大幅に拡張されていますので、新たなデプロイメントではこのバージョンを使用することをお薦めします。SAML IDアサーション・プロバイダ・バージョン1はWebLogic Server 9.1で非推奨になりました。セキュリティ・レルムには複数のSAML IDアサーション・プロバイダを含むことはできません。また、セキュリティ・レルムにSAML IDアサーション・プロバイダとSAML資格証明マッピング・プロバイダの両方が含まれる場合は、両方のバージョンが同じでなければなりません。バージョン2のSAMLプロバイダと同じセキュリティ・レルム内でバージョン1のSAMLプロバイダを使用しないでください。SAML IDアサーション・プロバイダ・バージョン1の構成については、WebLogic Server 9.0ドキュメントの『WebLogic Serverの保護』のSAML IDアサーション・プロバイダの構成に関する項を参照してください。
SAML IDアサーション・プロバイダをSAMLシングル・サインオン構成で使用する方法は、第21章「SAMLを使用するWebブラウザとHTTPクライアントでのシングル・サインオンの構成」を参照してください。WebLogic ServerでのSAMLのサポートの概要については、『Oracle WebLogic Serverセキュリティの理解』のSAML (Security Assertion Markup Language)に関する項を参照してください。
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 IDアサーション・プロバイダは、SAML 2.0セキュリティ・アサーションのコンシューマとして機能します。WebLogic Serverは、このプロバイダを使用することで、以下を実現するためのサービス・プロバイダとして機能します。
Webシングル・サインオン
WebLogic Webサービス・セキュリティ。適切なWS-SecurityPolicyアサーションを使用して、IDのSAMLトークンを受け付けます。
SAML 2.0 IDアサーション・プロバイダは、以下の役割を果たします。
署名をチェックし、パートナ用に構成されたデータに基づいて信頼性を検証することによって、SAML 2.0アサーションを検証します。次に、SAML 2.0 IDアサーション・プロバイダはアサーションに含まれているID情報を抽出し、それをセキュリティ・レルム内のローカル・サブジェクトにマップします。
必要に応じて、アサーションに含まれている属性情報を抽出します。SAML認証プロバイダがセキュリティ・レルム内に構成されている場合は、この属性情報を使用して、マップしたサブジェクトが属すローカル・グループを特定することも可能です。(詳細は、第16章「SAML認証プロバイダの構成」を参照してください。)
必要に応じて、アサーションに指定された有効期間や再利用の設定が有効かどうかを検証し、期限が切れている場合や再利用が不可能な場合はアサーションを拒否します。
SAML 2.0 IDアサーション・プロバイダの構成は、SAML2IdentityAsserterMBeanの属性を設定することで制御できます。SAML2IdentityAsserterMBeanにアクセスするには、WebLogic Scripting Tool (WLST)を使用するか、WebLogic Server管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「認証」ページを使用して、SAML2IdentityAsserterを作成または選択します。これらの属性の詳細は、Oracle WebLogic Server MBeanリファレンスのSAML2IdentityAsserterMBeanを参照してください。
SAML IDアサーション・プロバイダをSAML2.0シングル・サインオン構成で使用する方法は、第21章「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としての使用に関する項を参照してください。
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サービス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つの特殊文字を表します。表18-2に示すように、この接頭辞によってパートナ・ルックアップの実行方法が決まります。
|
注意: サービス・プロバイダとして機能するように構成されたWebLogic Serverインスタンスでは常に、SAML 2.0 IDアサーション・プロバイダに渡すエンドポイントURLからtransport、host、portの部分が除去されます。したがって、IDプロバイダ・パートナ用のルックアップ文字列として指定するすべてのエンドポイントURLには、hostとportより後ろの部分のみを含める必要があります。たとえば、target:*:/myserver/xxxのようにします。
これにより、サービス・プロバイダ・サイトを構成する際に、あるWebサービスをホストするドメイン内の複数のマシンで使用するトランスポート・プロトコル(たとえばHTTPかHTTPSか)、ホスト名、IPアドレス、ポート情報が違っていても、そのWebサービスのすべてのアサーションを単一のIDプロバイダ・パートナで検証することが可能になります。 |
表18-2 IDプロバイダ・パートナ・ルックアップ文字列の構文
| ルックアップ文字列 | 説明 |
|---|---|
target:-:<endpoint-url>
|
URL この形式のパートナ・ルックアップ文字列の場合、エンドポイントURLは、このIDプロバイダ・パートナのオーディエンスURIとしては追加されません。 |
target:+:<endpoint-url>
|
URL 注意: プラス記号( |
target:*:<endpoint-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管理コンソールのパートナ管理ページにある「トランスポート層クライアント証明書」タブを使用します。
Webサービス・パートナの属性は、com.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して操作できます。
HTTPリクエストが送信されたときに、IDアサーションに使用できる一致が複数存在する場合があります。一方、IDアサーション・プロバイダが一度に消費できるのは1つのアクティブなトークン・タイプだけです。つまり、一度の呼出しで一連のトークンを消費できる方法は提供されていません。したがってWebLogic Serverに含まれるサーブレットでは、IDアサーションを実行するために複数のトークンから1つを選択する必要があります。選択は次の順序で行われます。
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ヘッダーを持ち、BARCookieを持つリクエストが受信される場合、FOOトークンがIDアサーションに使用されます。
同じレベルの複数のトークン間の順序付けは定義されていません。そのため、次のようになります。
FOOヘッダーを持ち、BARヘッダーを持つリクエストが受信される場合、FOOトークンまたはBARトークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。
FOOCookieを持ち、BARCookieを持つリクエストが受信される場合、FOOトークンまたはBARトークンのいずれかがIDアサーションに使用されますが、どちらが使用されるかは不確定です。
IDアサーション・プロバイダ(X.509証明書またはその他のトークン)を使用する場合、サブジェクトはサーバーにキャッシュされます(サブジェクトとは、単一のエンティティ(個人など)に関連する情報のグループで、IDやそのセキュリティ関連の構成オプションなどが含まれます)。サーバー内にサブジェクトをキャッシュすると、<run-as>タグのあるサーブレットおよびEJBメソッドや、HTTPSessionでIDアサーションが使用されるがキャッシュはされないような他の状況(XMLドキュメントの署名や暗号化など)におけるパフォーマンスが大幅に向上します。
|
注意: キャッシングは、セマンティクスに違反することがあります。 |
このキャッシュ内の項目の存続期間を変更するには、-Dweblogic.security.identityAssertionTTLコマンド・ライン引数を使用してサブジェクトがキャッシュに存在できる最大秒数を設定します。このコマンド・ライン引数のデフォルトは300秒(5分)です。コマンド・ライン引数に指定できる値は次のとおりです。
0より小さい値 - キャッシュを無効化します。
0 - キャッシュは有効であり、キャッシュ内のIDはサーバーが実行中である限り、タイムアウトになりません。キャッシュされたエントリのユーザー・データベースが変更された場合は、サーバーがエントリを取得するために必ずサーバーの再起動が必要になります。
0より大きい値 - キャッシュは有効であり、キャッシュは指定された秒数でリセットされます。
IDアサーションのパフォーマンスを向上させるには、このコマンド・ライン引数により大きな値を指定します。
|
注意: IDアサーションのパフォーマンスが上がるにつれて、IDアサーション・プロバイダは構成されている認証プロバイダの変化に反応しなくなります。たとえば、ユーザーのグループの変更は、サブジェクトがキャッシュからフラッシュされて再作成されるまで反映されなくなります。このコマンド・ライン引数でより小さい値を指定すると、認証変更の反応は良くなりますが、パフォーマンスは低下します。 |
WebLogic IDアサーション・プロバイダでは、セキュリティ・レルムのアイデンティティ・ストアに定義されていないユーザーを認証する機能がサポートされます。この場合、ユーザーは仮想ユーザーとして作成され、プリンシパルが設定されたサブジェクトを使用して認証されます。このプリンシパルは、双方向SSL接続の一環として渡されるX.509証明書の属性から導出されます。
WebLogic IDアサーション・プロバイダは、デフォルトでは仮想ユーザーを認証するように構成されていません。ただし、このプロバイダの構成をカスタマイズすることにより、WebLogicドメインでこの機能を有効化できます。
|
注意: 仮想ユーザー認証は、双方向SSLに対応するように構成され、CLIENT-CERT認証を使用するリスニング・サーブレットを備えたネットワーク・ポートのみでサポートされます。
仮想ユーザー認証は次のようなトポロジではサポートされません。
|
次の項で、仮想ユーザー認証の仕組みを説明して、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サーバーなど)が使用されることはありません。
仮想ユーザーをWebLogicドメインで認証できるようにWebLogicセキュリティ・フレームワークを構成する前に、ドメインのSSL構成を最適化し、WebLogic Serverの証明書検証機能を利用することを強くお薦めします。次の手順を実行して、クライアント証明書が問題なく信頼できることと検証されていることを確認します。
双方向SSL (クライアント認証を含むSSL)を構成します。双方向SSLでは、サーバーがクライアントに証明書を提示し、クライアントがサーバーに証明書を提示します。
SSL接続で有効な最小のSSLバージョンを制限するようにSSLを構成します。詳細は、第37章「SSLプロトコル・バージョンの指定」を参照してください。
SSL証明書の検証がドメインで適切に構成されていることを確認します。詳細は、第34章「SSL証明書の検証」を参照してください。
X.509証明書失効(CR)チェックを構成します。X.509証明書失効チェックによって、SSL証明書パス検証プロセスの一部として、証明書の失効ステータスがチェックされます。CRチェックによって、受け取った証明書が発行元の認証局によって失効されていないことが保証され、証明書の使用におけるセキュリティが向上します。詳細は、第39章「X.509証明書失効チェック」を参照してください。
WebLogic IDアサーション・プロバイダ(DefaultIdentityAsserter)はWebLogicドメインでデフォルトで構成されています。仮想ユーザーの認証を有効にするには、WebLogicドメインでこのプロバイダのデフォルト・インスタンスをカスタマイズします。または、このプロバイダの別のインスタンスを作成してそれをカスタマイズします。
仮想ユーザー認証を有効にするようにWebLogic IDアサーション・プロバイダを構成するには、次の手順を実行します。
このプロバイダがX.509トークン・タイプを処理するように構成します。これはDefaultIdentityAsserterMBean.ActiveTypes属性で設定できます。
WebLogic Server管理コンソールを使用してこの属性を設定するには、WebLogic IDアサーション・プロバイダを選択して、「構成」→「共通」ページに移動します。「アクティブなタイプ」フィールドで、X.509トークン・タイプを選択して「選択済み」リストに移動します。
仮想ユーザーを有効にします。これには、DefaultIdentityAsserterMBean.VirtualUserAllowed属性をtrueに設定します。
WebLogic Server管理コンソールを使用してこの属性を設定するには、WebLogic IDアサーション・プロバイダの「構成」→「プロバイダ固有」に移動し、仮想ユーザーの許可を選択します。
デフォルト・ユーザー名マッパーを有効にします。これには、DefaultIdentityAsserterMBean.UseDefaultUserNameMapper属性をtrueに設定します。
WebLogic Server管理コンソールを使用してこの属性を設定するには、「デフォルト・ユーザー名マッパーの使用」を選択します。これもWebLogic IDアサーション・プロバイダの「構成」→「プロバイダ固有」にあります。
これらの手順の操作方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「アイデンティティ・ストアに定義されていないユーザーの認証」を参照してください。
WebLogic Serverでは、weblogic.security.providers.authentication.X509SubjectComponentMapperインタフェースの実装であるカスタム・ユーザー名マッパーも使用できます。X.509証明書の他の属性(グループ・プリンシパル、プライベート資格証明またはパブリック資格証明など)をマップする必要がある場合は、カスタム・ユーザー名マッパーの使用をお薦めします。
仮想ユーザー認証プロバイダはデフォルトではWebLogicドメインで使用できません。このプロバイダの構成方法の詳細は、第19章「仮想ユーザー認証プロバイダの構成」を参照してください。このプロバイダをセキュリティ・レルムに追加した後で、次の操作を実行します。
仮想ユーザー認証プロバイダが最初になるように認証プロバイダの順序を変更します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「認証プロバイダの順序変更」を参照してください。
仮想ユーザー認証プロバイダのJAAS制御フラグをSUFFICIENTに設定します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JAAS制御フラグの設定」を参照してください。
この項では、WebLogicドメインでの仮想ユーザー認証の構成例を示します。例18-1は、次のことを示しています。
WebLogic Serverインスタンスに接続します。
仮想ユーザー認証プロバイダのインスタンスを作成します。
セキュリティ・レルムの認証プロバイダの中で仮想ユーザー認証プロバイダが最初になるように順序を設定します。
WebLogic IDアサーション・プロバイダ(DefaultIdentityAsserter)で仮想ユーザーを有効にします。
WebLogic Serverによって提供されるデフォルト・ユーザー名マッパーを有効にします。
変更内容を保存してセキュリティ・レルムでアクティブ化します。
例18-1 仮想ユーザー認証プロバイダの構成と仮想ユーザーの有効化
connect(user, passwd, wlsServer)
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()
WebLogic Serverは、双方向SSL接続を確立するときにWebブラウザまたはJavaクライアントのデジタル証明書を確認します。ただし、デジタル証明書はWebブラウザまたはJavaクライアントをWebLogic Serverセキュリティ・レルムのユーザーとしては認識しません。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストすると、WebLogic ServerはWebブラウザまたはJavaクライアントにIDを持つように要求します。WebLogic IDアサーション・プロバイダで有効にできるユーザー名マッパーを使用して、次のいずれかをマップできます。
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 Serverのユーザー名または仮想ユーザーにマップすることもできます。
トークンをWebLogicユーザーにマップするカスタム・ユーザー名マッパーは、weblogic.security.providers.authentication.UserNameMapperインタフェースの実装でなければなりません。
仮想ユーザー(セキュリティ・レルムのアイデンティティ・ストアに定義されていないユーザー)の認証に使用されるサブジェクト・プリンシパルにX.509トークンをマップするカスタム・ユーザー名マッパーは、weblogic.security.providers.authentication.X509SubjectComponentMapperインタフェースの実装でなければなりません。
X.509証明書の他の属性(グループ・プリンシパル、プライベート資格証明またはパブリック資格証明など)をマップする必要がある場合は、カスタム・ユーザー名マッパーの使用をお薦めします。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。
