| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発 11g リリース 1 (10.3.1) B55527-01 |
|
戻る |
次へ |
ID アサーション プロバイダは、ユーザまたはシステム プロセスがトークンを使用してそれぞれの ID を証明する特殊な形態 (つまり境界認証) の認証プロバイダです。ID アサーション プロバイダは境界認証を有効にし、シングル サインオンをサポートします。ID アサーション プロバイダ用の LoginModule を作成すれば、認証プロバイダの代わりに ID アサーション プロバイダを使用できます。また、認証プロバイダの LoginModule を使用する場合は、認証プロバイダに加えて ID アサーション プロバイダも使用できます。
ID アサーション プロバイダを認証プロバイダとは別にコンフィグレーションできるようにするには、2 つのプロバイダを作成します。ID アサーション プロバイダと認証プロバイダが独立して機能できない場合は、1 つのプロバイダを作成します。
以下の節では、ID アサーション プロバイダの概念と機能、およびカスタム ID アサーション プロバイダの開発手順について説明します。
ID アサーション プロバイダを開発する前に、以下の概念を理解しておく必要があります。
LoginModule と一緒に用いると、ID アサーション プロバイダはシングル サインオンをサポートします。たとえば、ID アサーション プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザは何度もサインオンを求められることはありません。
ID アサーション プロバイダが使用する LoginModule では、以下のことが可能です。
開発したカスタム認証プロバイダの一部となる。詳細については、「認証プロバイダ」を参照してください。
Oracle が開発し WebLogic Server と一緒にパッケージ化した WebLogic 認証プロバイダの一部になる。詳細については、「カスタム認証プロバイダを開発する必要があるか」を参照してください。
サード パーティのセキュリティ ベンダの認証プロバイダの一部となる。
単純認証の場合と違って (「認証プロセス」を参照)、ID アサーション プロバイダが使用する LoginModule は証明情報 (ユーザ名やパスワードなど) を検証しません (単にユーザが存在することを検証するだけです)。
このコンフィグレーションの LoginModule は以下の処理を行う必要があります。
WLSGroup 型などの必須のプリンシパルをサブジェクトに格納する。
ユーザがログインのための十分な証明を提供していると見なし、パスワードなどの証明データを要求しない。
「AuthenticationProviderV2 SSPI の実装」の説明に従って、カスタム認証プロバイダに AuthenticationProviderV2.getAssertionModuleConfiguration メソッドを実装する必要があります。このメソッドは、X.509 証明書を使用している場合などに、ID アサーションがデプロイメント記述子の run-as タグを処理するために呼び出されます。他のシングル サインオン方式でも、このメソッドを使用します。
ID アサーション プロバイダは、ユーザまたはシステム プロセスの ID を断定するために使用する特定のトークン タイプをサポートするために開発します。ID アサーション プロバイダは複数のトークン タイプをサポートするように開発できますが、通常はただ 1 つの「アクティブ」なトークン タイプを検証するようにコンフィグレーションされます。同じトークン タイプを検証する複数の ID アサーション プロバイダを 1 つのセキュリティ レルムに組み込むことも可能ですが、実際に検証を行うのは 1 つの ID アサーション プロバイダだけです。
|
注意 : トークン タイプを「サポート」するということは、id アサーション プロバイダの実行時クラス (IdentityAsserter SSPI 実装) がその assertIdentity メソッドでトークン タイプを検証できるということです。詳細については、「IdentityAsserterV2 SSPI の実装」を参照してください。 |
以下の節では、新しいトークン タイプを使用するための手順について説明します。
カスタム ID アサーション プロバイダを開発する場合には、新しいトークン タイプも作成できます。トークン タイプとは、文字列で表される 1 つのデータに過ぎません。どのようなトークン タイプを作成して使用するかは、完全にユーザに任されています。たとえば、現在 WebLogic ID アサーション プロバイダ用に定義されているトークンには、X.509、CSI.PrincipalName、CSI.ITTAnonymous、CSI.X509CertChain、CSI.DistinguishedName、AUTHORIZATION_NEGOTIATE、SAML.Assertion64、SAML.Assertion.DOM、SAML.Assertion、WWW-AUTHENTICATE_NEGOTIATE など、さまざまなタイプがあります。
新しいトークン タイプを作成するには、コード リスト 5-1 に示すとおり、新しい Java ファイルを作成し、String 型の変数として新しいトークン タイプを宣言します。PerimeterIdentityAsserterTokenTypes.java ファイルでは、Test 1、Test 2、および Test 3 というトークン タイプの名前が文字列として定義されています。
コード リスト 5-1 PerimeterIdentityAsserterTokenTypes.java
package sample.security.providers.authentication.perimeterATN;
public class PerimeterIdentityAsserterTokenTypes
{
public final static String TEST1_TYPE = 'Test 1";
public final static String TEST2_TYPE = 'Test 2";
public final static String TEST3_TYPE = 'Test 3";
}
カスタム ID アサーション プロバイダをコンフィグレーションする場合 (「Administration Console によるカスタム ID アサーション プロバイダのコンフィグレーション」を参照)、ID アサーション プロバイダのサポートするトークン タイプのリストが [サポートされている種類] フィールドに表示されます。図 5-1 に示すとおり、サポートされているタイプの 1 つを [アクティブな種類] フィールドに入力します。
[サポートされている種類] フィールドの内容は、カスタム ID アサーション プロバイダの MBean タイプを生成するために使用する MBean 定義ファイル (MDF) の SupportedTypes 属性から取得されます。サンプル ID アサーション プロバイダの例をコード リスト 5-2 に示します (MDF および MBean タイプの詳細については、「WebLogic MBeanMaker による MBean タイプの生成」を参照)。
コード リスト 5-2 SampleIdentityAsserter MDF : SupportedTypes 属性
<MBeanType> ... <MBeanAttribute Name = "SupportedTypes" Type = "java.lang.String[]" Writeable = "false" Default = "new String[] {"SamplePerimeterAtnToken"}" /> ... </MBeanType>
同様に、[アクティブな種類] フィールドの内容は MBean 定義ファイル (MDF) の ActiveTypes 属性から取得されます。MDF ファイルの ActiveTypes 属性をデフォルトに設定すると、WebLogic Server Administration Console で手動設定する必要がなくなります。サンプル ID アサーション プロバイダの例をコード リスト 5-3 に示します。
コード リスト 5-3 SampleIdentityAsserter MDF: Default を使用した ActiveTypes 属性
<MBeanAttribute Name= "ActiveTypes" Type= "java.lang.String[]" Default = "new String[] { "SamplePerimeterAtnToken" }" />
ActiveTypes 属性のデフォルト化は便利ですが、他の ID アサーション プロバイダがそのトークン タイプを検証することがない場合にのみ行うようにします。その場合以外は、無効なセキュリティ レルムがコンフィグレーションされることになるおそれがあります (複数の ID アサーション プロバイダが同じトークン タイプを検証しようとする)。一番良いのは、ID アサーション プロバイダのすべての MDF がデフォルトでそのトークン タイプをオフにすることです。その場合、そのトークン タイプを検証する ID アサーション プロバイダをコンフィグレーションして手作業でアクティブにすることができます。
|
注意 : ID アサーション プロバイダが目的のトークン タイプを検証して受け入れるように開発およびコンフィグレーションされていない場合、認証プロセスは失敗します。ID アサーション プロバイダのコンフィグレーションの詳細については、「Administration Console によるカスタム ID アサーション プロバイダのコンフィグレーション」を参照してください。 |
ID アサーション プロバイダは、境界認証のために Java クライアントからサーブレットにトークンを渡すことができます。トークンは、HTTP ヘッダ、クッキー、SSL 証明書などのメカニズムを用いて渡すことができます。たとえば、HTTP ヘッダを使用すれば、Base64 でコード化された文字列 (バイナリ データの送信が可能) をサーブレットに送信することができます。この文字列の値は、ユーザ名などのユーザの ID を表す文字列です。境界認証に使用される ID アサーション プロバイダは、その文字列を受け取り、そこからユーザ名を抽出できます。
トークンが HTTP ヘッダまたはクッキーを通じて渡される場合には、そのトークンはヘッダまたはクッキーの名前に等しく、リソース コンテナは WebLogic Security フレームワークの認証を処理するパートにトークンを渡します。WebLogic Security フレームワークは、そのトークンをそのまま ID アサーション プロバイダに渡します。
WebLogic Server は、ID アサーションのサポートを介して境界までシングル サインオン概念を拡張できるよう設計されています。ID アサーションを使用すると、WebLogic Server は、SAML (Security Assertion Markup Language)、SPNEGO (Simple and Protected GSS-API Negotiation)、または Common Secure Interoperability (CSI) v2 などのプロトコルに対する拡張といった境界認証方式によって提供される認証メカニズムを使用して、この機能を実現できます。
WebLogic Server では、IIOP (Internet Inter-ORB) (GIOP バージョン 1.2) および CORBA CSIv2 (Common Secure Interoperability version 2) 仕様に基づいた EJB (エンタープライズ JavaBean) 相互運用性プロトコルをサポートしています。WebLogic Server で CSIv2 をサポートすることにより、以下のことが可能になります。
J2EE (Java 2 Enterprise Edition) バージョン 1.4 の参照実装と相互運用できる。
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 クライアント、あるいは別の J2EE アプリケーション サーバに対するクライアントの役目をする WebLogic Server インスタンスで使用することができます。CSIv2 サポート用の JAAS LoginModule は UsernamePasswordLoginModule という名前で、weblogic.security.auth.login パッケージに格納されています。
CSIv2 は以下のように動作します。
IOR (Interoperable Object Reference) へのセキュリティ拡張機能の作成時に、WebLogic Server は、CORBA オブジェクトでサポートされるセキュリティ メカニズムを識別するタグ付きコンポーネントを追加します。このタグ付きコンポーネントには、転送情報、クライアント認証情報、および ID 証明トークン/認可トークン情報が入っています。
クライアントは、IOR 内のセキュリティ メカニズムを評価し、サーバが必要とするオプションをサポートするメカニズムを選択します。
クライアントは SAS プロトコルを用いて、WebLogic Server とのセキュリティ コンテキストを確立します。SAS プロトコルは要求と応答からなるサービス コンテキスト内に含まれるメッセージを定義します。コンテキストはステートフルでもステートレスでもかまいません。
CSIv2 の利用については、『Oracle Fusion Middleware Oracle WebLogic Server Security の紹介』の「Common Secure Interoperability Version 2」を参照してください。JAAS LoginModule の詳細については、「LoginModule」を参照してください。
境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します (これは、WebLogic Server がユーザ名とパスワードを通じて信頼を確立する、「認証プロセス」で説明されているタイプの認証とは対照的です)。ID アサーション プロバイダは、下記の図のように機能する境界認証プロセスの一部として使用されます (図 5-2 を参照)。
WebLogic Server の外部のトークンが、そのタイプのトークンの検証を担当し、「アクティブ」としてコンフィグレーションされている ID アサーション プロバイダに渡されます。
そのトークンの有効性が問題なく検証されれば、ID アサーション プロバイダはそのトークンを WebLogic Server ユーザ名にマップし、そのユーザ名を WebLogic Server に送り返します。その後 WebLogic Server では、「認証プロセス」で説明した方法で認証プロセスを続行します。具体的には、ユーザ名が JAAS (Java Authentication and Authorization Service) CallbackHandler を通じて送信され、コンフィグレーションされている各認証プロバイダの LoginModule に渡されて、サブジェクト内に適切なプリンシパルを格納できるようになります。
図 5-2 でも示されているように、境界認証では「認証プロセス」で説明されている認証プロセスと同じ構成要素が必要ですが、そこに ID アサーション プロバイダも追加されます。
WebLogic ID アサーション プロバイダでは、X509 証明書を使用した証明書認証、SPNEGO トークン、SAML アサーション トークン、および CSIv2 (CORBA Common Secure Interoperability Version 2) ID アサーションがサポートされています。
LDAP X509 ID アサーション プロバイダは、X509 証明書を受け取り、その証明書に関連付けられたユーザの LDAP オブジェクトをルックアップして、LDAP オブジェクトの証明書が提示された証明書と一致することを確認し、LDAP オブジェクトから認証用にユーザの名前を取得します。
ネゴシエート ID アサーション プロバイダは、SPNEGO プロトコルをサポートする Microsoft クライアントでの SSO に使用します。ネゴシエート ID アサーション プロバイダは、SPNEGO トークンをデコードして Kerberos トークンを入手し、この Kerberos トークンを検証して WebLogic ユーザにマップします。ネゴシエート ID アサーション プロバイダは、Kerberos を介した GSS のセキュリティ コンテキストの受け入れに Java GSS (Generic Security Service) API (Application Programming Interface) を利用します。ネゴシエート ID アサーション プロバイダは、Windows NT 統合ログイン用です。
SAML ID アサーション プロバイダは、WebLogic Server が SAML 送り先サイトとして動作するときに SAML アサーション トークンを処理します。SAML ID アサーション プロバイダは、SAML アサーション トークンを消費および検証し、アサーションを信頼するかどうかを決定します (SOAP メッセージの証明データ、クライアント証明書、またはその他のコンフィグレーション インジケータを使用)。
デフォルトの WebLogic ID アサーション プロバイダはトークン タイプを検証し、X509 デジタル証明書と X501 識別名を WebLogic ユーザ名にマップします。また、CSIv2 ID アサーションに使用する信頼性のあるクライアント プリンシパルのリストも指定します。ワイルドカード文字 (*) を使用すると、すべてのプリンシパルに信頼性があると指定できます。クライアントが信頼性のあるクライアント プリンシパルのリストにない場合は、CSIv2 ID アサーションが失敗し、呼び出しが拒否されます。
|
注意 : X.501 および X.509 証明書に対して WebLogic ID アサーション プロバイダを使用するには、WebLogic Server 製品に付属しているデフォルトのユーザ名マッパー (weblogic.security.providers.authentication.DefaultUserNameMapperImpl) を使用するか、または独自の weblogic.security.providers.authentication.UserNameMapper インタフェースの実装を用意します。このインタフェースは、必要に応じた方式に従って、X.509 証明書を WebLogic Server のユーザ名にマップします。また、このインタフェースを使用して X.501 識別名をユーザ名にマップすることもできます。Administration Console を使用して ID アサーション プロバイダをコンフィグレーションするときに、このインタフェースの実装を指定します。 |
WebLogic ID アサーション プロバイダでは、以下のトークン タイプがサポートされています。
AU_TYPE - WebLogic AuthenticatedUser がトークンとして使用される場合に使用します。
X509_TYPE - X509 クライアント証明書がトークンとして使用される場合に使用します。
CSI_PRINCIPAL_TYPE - CSIv2 プリンシパル名 ID がトークンとして使用される場合に使用します。
CSI_ANONYMOUS_TYPE - CSIv2 匿名 ID がトークンとして使用される場合に使用します。
CSI_X509_CERTCHAIN_TYPE - CSIv2 X509 証明書チェーン ID がトークンとして使用される場合に使用します。
CSI_DISTINGUISHED_NAME_TYPE - CSIv2 識別名 ID がトークンとして使用される場合に使用します。
AUTHORIZATION_NEGOTIATE - SPNEGO 内部トークンがトークンとして使用される場合に使用します。
SAML_ASSERTION_B64_TYPE - Base64 エンコード SAML.アサーションがトークンとして使用される場合に使用します。
SAML_ASSERTION_DOM_TYPE - SAML DOM 要素がトークンとして使用される場合に使用します。
SAML_ASSERTION_TYPE - SAML 文字列 XML 形式がトークンとして使用される場合に使用します。
SAML_SSO_CREDENTIAL_TYPE - TARGET パラメータで構成される SAML 文字列がアサーション自体と連結され、トークンとして使用される場合に使用します。
WSSE_PASSWORD_DIGEST_TYPE - パスワード ダイジェストのパスワード タイプを持つユーザ名トークンがトークンとして使用される場合に使用します。
WWW_AUTHENTICATE_NEGOTIATE - SPNEGO 内部トークンがトークンとして使用される場合に使用します。
追加的な ID アサーション タスクを実行したい場合、または新しいトークン タイプを作成したい場合は、カスタム ID アサーション プロバイダを開発する必要があります。
WebLogic ID アサーション プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム ID アサーション プロバイダを開発することができます。
「チャレンジ ID アサーション」の説明に従って、チャレンジ ID アサーションを実装する必要があるかどうかを考慮します。
実行時クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ID アサーション プロバイダの実行時クラスを作成します。
|
注意 : カスタム ID アサーション プロバイダ用に別の LoginModule を作成する (認証プロバイダの LoginModule を使用しない) 場合は、JAAS LoginModule インタフェースも実装する必要があります。(「JAAS LoginModule インタフェースの実装」を参照)。 |
カスタム ID アサーション プロバイダの実行時クラスの作成例については、「例 : サンプル ID アサーション プロバイダの実行時クラスの作成」を参照してください。
|
注意 : AuthenticationProvider SSPI は、このリリースの WebLogic Server では非推奨になっています。AuthenticationProviderV2 SSPI を代わりに使用してください。 |
AuthenticationProviderV2 SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getLoginModuleConfiguration
public AppConfigurationEntry getLoginModuleConfiguration()
getLoginModuleConfiguration メソッドは、認証プロバイダの関連付けられた LoginModule に関する情報を取得します。その情報は、AppConfigurationEntry として返されます。AppConfigurationEntry は、LoginModule のクラス名、認証プロバイダの関連する MBean を通じて渡された LoginModule の制御フラグ、および他のコンフィグレーション情報を LoginModule に渡すことを可能にする LoginModule のコンフィグレーション オプション マップの格納された JAAS (Java Authentication and Authorization Service) クラスです。
(javax.security.auth.login パッケージ内にある) AppConfigurationEntry クラスと LoginModule の制御フラグ オプションの詳細については、J2SE 6.0 API 仕様の (http://java.sun.com/javase/6/docs/api/javax/security/auth/login/AppConfigurationEntry.html) 「AppConfigurationEntry クラス」および (http://java.sun.com/javase/6/docs/api/javax/security/auth/login/Configuration.html) 「コンフィグレーション クラス」を参照してください。 LoginModule の詳細については、「LoginModule」を参照してください。セキュリティ プロバイダと MBean の詳細については、「MBean タイプが必要な理由について」を参照してください。
getAssertionModuleConfiguration
public AppConfigurationEntry getAssertionModuleConfiguration()
getAssertionModuleConfiguration メソッドは、ID アサーション プロバイダの関連付けられた LoginModule に関する情報を取得します。その情報は、AppConfigurationEntry として返されます。AppConfigurationEntry は、LoginModule のクラス名、ID アサーション プロバイダの関連する MBean を通じて渡された LoginModule の制御フラグ、および他のコンフィグレーション情報を LoginModule に渡すことを可能にする LoginModule のコンフィグレーション オプション マップの格納された JAAS クラスです。
このコンフィグレーションの LoginModule は、WLSGroup 型などの必須のプリンシパルをサブジェクトに格納する必要があります。また、ユーザがログインのための十分な証明を提供していると見なし、パスワードなどの証明データを要求しません。
|
注意 : ID アサーション プロバイダの assertidentity() メソッドは、ID アサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModule は呼び出されないことがあります。-Dweblogic.security.identityAssertionTTL フラグを使うと、この動作を変更する (たとえば、5 分というデフォルト TTL を変更する、またはフラグを -1 に設定してキャッシュを無効にする) ことができます。
トークンが有効なだけでなく、ユーザも引き続き有効であること (ユーザが削除されていないことなど) を確認するのは、ID アサーション プロバイダの役割です。 |
getPrincipalValidator
public PrincipalValidator getPrincipalValidator()
getPrincipalValidator メソッドは、プリンシパル検証プロバイダの実行時クラス (PrincipalValidator SSPI 実装) の参照を取得します。詳細については、「プリンシパル検証プロバイダ」を参照してください。
getIdentityAsserter
public IdentityAsserterV2 getIdentityAsserter()
getIdentityAsserter メソッドは、ID アサーション プロバイダの実行時クラス (IdentityAsserterV2 SSPI 実装) の参照を取得します。詳細については、「IdentityAsserterV2 SSPI の実装」を参照してください。
|
注意 : ID アサーション プロバイダ用の LoginModule が既存の認証プロバイダ用の LoginModule と同じである場合、ID アサーション プロバイダ用の AuthenticationProviderV2 SSPI 内のメソッドの実装 (getIdentityAsserter メソッドを除く) は null を返す場合があります。この場合の例については、コード リスト 5-4 に示します。 |
AuthenticationProvider SSPI と上記メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
|
注意 : IdentityAsserterV2 SSPI には、追加のトークン タイプと、id アサーション時に必要に応じて追加情報の取得に使用できる assertIdentity メソッドに対する handler パラメータが含まれます。IdentityAsserter SSPI もサポートされていますが、代わりに IdentityAsserterV2 SSPI の使用を考慮してください。 |
IdentityAsserterV2 SSPI を実装するには、以下のメソッドの実装を提供する必要があります。
assertIdentity
public CallbackHandler assertIdentity(String type, Object token, ContextHandler handler) throws IdentityAssertionException;
assertIdentity メソッドは、提供されたトークンの ID 情報に基づいて ID を断定します。言い換えれば、このメソッドの目的は、現時点で「信頼性のない」トークンがあれば、それを信頼性のあるクライアント プリンシパルに照らし合わせて検証することです。type パラメータは、ID アサーション (ID の断定) に使用するトークン タイプを表します。ID アサーション タイプには大文字/小文字の区別はありません。また、token パラメータには実際の ID 情報が格納されています。handler パラメータは、ID アサーションで使用可能な追加情報を取得する際に必要に応じて使用できる ContextHandler オブジェクトです。assertIdentity メソッドから返される CallbackHandler は、断定されたユーザ名を格納している必要があり、プリンシパル マッピングを行うためにコンフィグレーションされているすべての認証プロバイダの LoginModule に渡されます。CallbackHandler が null の場合、匿名ユーザを使用することを意味します。
CallbackHandler は、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟な JAAS 規格です。CallbackHandler の詳細については、J2SE 6.0 API 仕様の (http://java.sun.com/javase/6/docs/api/javax/security/auth/callback/CallbackHandler.html) 「CallbackHandler インタフェース」を参照してください。
|
注意 : ID アサーション プロバイダの assertidentity() メソッドは、ID アサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModule は呼び出されないことがあります。-Dweblogic.security.identityAssertionTTL フラグを使うと、この動作を変更する (たとえば、5 分というデフォルト TTL を変更する、またはフラグを -1 に設定してキャッシュを無効にする) ことができます。トークンが有効なだけでなく、ユーザも引き続き有効であること (ユーザが削除されていないことなど) を確認するのは、ID アサーション プロバイダの役割です。 |
IdentityAsserterV2 SSPI と上記メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。
コード リスト 5-4 は、サンプル ID アサーション プロバイダの実行時クラスである SampleIdentityAsserterProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、およびshutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的について」を参照)。
getLoginModuleConfiguration、getAssertionModuleConfiguration、getPrincipalValidator、および getIdentityAsserter という AuthenticationProviderV2 SSPI の 4 つのメソッド (「AuthenticationProviderV2 SSPI の実装」を参照)。
assertIdentity という IdentityAsserterV2 SSPI のメソッド (「IdentityAsserterV2 SSPI の実装」を参照)。
コード リスト 5-4 SampleIdentityAsserterProviderImpl.java
package examples.security.providers.identityassertion.simple; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.login.AppConfigurationEntry; import weblogic.management.security.ProviderMBean; import weblogic.security.service.ContextHandler; import weblogic.security.spi.AuthenticationProviderV2; import weblogic.security.spi.IdentityAsserterV2; import weblogic.security.spi.IdentityAssertionException; import weblogic.security.spi.PrincipalValidator; import weblogic.security.spi.SecurityServices; public final class SimpleSampleIdentityAsserterProviderImpl implements AuthenticationProviderV2, IdentityAsserterV2 { final static private String TOKEN_TYPE = "SamplePerimeterAtnToken"; final static private String TOKEN_PREFIX = "username="; private String description; public void initialize(ProviderMBean mbean, SecurityServices services) { System.out.println("SimpleSampleIdentityAsserterProviderImpl.initialize"); SimpleSampleIdentityAsserterMBean myMBean = (SimpleSampleIdentityAsserterMBean)mbean; description = myMBean.getDescription() + "\n" + myMBean.getVersion(); } public String getDescription() { return description; } public void shutdown() { System.out.println("SimpleSampleIdentityAsserterProviderImpl.shutdown"); } public IdentityAsserterV2 getIdentityAsserter() { return this; } public CallbackHandler assertIdentity(String type, Object token, ContextHandler context) throws IdentityAssertionException { System.out.println("SimpleSampleIdentityAsserterProviderImpl.assertIdentity"); System.out.println("\tType\t\t= " + type); System.out.println("\tToken\t\t= " + token); if (!(TOKEN_TYPE.equals(type))) { String error = "SimpleSampleIdentityAsserter received unknown token type \"" + type + "\"." + " Expected " + TOKEN_TYPE; System.out.println("\tError: " + error); throw new IdentityAssertionException(error); } if (!(token instanceof byte[])) { String error = "SimpleSampleIdentityAsserter received unknown token class \"" + token.getClass() + "\"." + " Expected a byte[]."; System.out.println("\tError: " + error); throw new IdentityAssertionException(error); } byte[] tokenBytes = (byte[])token; if (tokenBytes == null || tokenBytes.length < 1) { String error = "SimpleSampleIdentityAsserter received empty token byte array"; System.out.println("\tError: " + error); throw new IdentityAssertionException(error); } String tokenStr = new String(tokenBytes); if (!(tokenStr.startsWith(TOKEN_PREFIX))) { String error = "SimpleSampleIdentityAsserter received unknown token string \"" + type + "\"." + " Expected " + TOKEN_PREFIX + "username"; System.out.println("\tError: " + error); throw new IdentityAssertionException(error); } String userName = tokenStr.substring(TOKEN_PREFIX.length()); System.out.println("\tuserName\t= " + userName); return new SimpleSampleCallbackHandlerImpl(userName); } public AppConfigurationEntry getLoginModuleConfiguration() { return null; } public AppConfigurationEntry getAssertionModuleConfiguration() { return null; } public PrincipalValidator getPrincipalValidator() { return null; } }
コード リスト 5-5 は、SampleIdentityAsserterProviderImpl.java 実行時クラスとともに使用する CallbackHandler のサンプル実装を示しています。この CallbackHandler の実装は、認証プロバイダの LoginModule にユーザ名を送り返すために使用します。
コード リスト 5-5 SampleCallbackHandlerImpl.java
package examples.security.providers.identityassertion.simple;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
/*package*/ class SimpleSimpleSampleCallbackHandler implements CallbackHandler
{
private String userName;
/*package*/ SimpleSampleCallbackHandlerImpl(String user)
{
userName = user;
}
public void handle(Callback[] callbacks) throws UnsupportedCallbackException
{
for (int i = 0; i < callbacks.length; i++) {
Callback callback = callbacks[i];
if (!(callback instanceof NameCallback)) {
throw new UnsupportedCallbackException(callback, "Unrecognized
Callback");
}
NameCallback nameCallback = (NameCallback)callback;
nameCallback.setName(userName);
}
}
}
カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ID アサーション プロバイダの MBean タイプを作成します。
WebLogic Server 環境に MBean タイプのインストール
|
注意 : この節で説明する手順はすべて、Windows 環境での作業を想定しています。 |
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
サンプル ID アサーション プロバイダの MDF をテキスト ファイルにコピーします。
|
注意 : サンプル ID アサーション プロバイダの MDF は、SampleIdentityAsserter.xml です。 |
MDF で <MBeanType> 要素と <MBeanAttribute> 要素の内容をカスタム ID アサーション プロバイダに合わせて修正します。次に、Base64DecodingRequired 属性を false に設定する例を示します。
<MBeanAttribute Name = "Base64DecodingRequired" Type = "boolean" Writeable = "false" Default = "false" Description = "See MyIdentityAsserter-doc.xml." />
カスタム属性および操作 (つまり、<MBeanAttribute> および <MBeanOperation> 要素) を MDF に追加します。
ファイルを保存します。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム ID アサーション プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム ID アサーション プロバイダの MDF に任意 SSPI MBean もカスタム操作も実装しない場合、次の手順に従います。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり ID アサーション プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
カスタム ID アサーション プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
MBean タイプを作成するのは初めてですか。初めての場合は、次の手順に従ってください。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり ID アサーション プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
任意 SSPI MBean を MDF に実装した場合は、次の手順に従います。
MBean 実装ファイルを見つけます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。 たとえば、SampleIdentityAsserter という名前の MDF の場合、編集される MBean 実装ファイルは SampleIdentityAsserterImpl.java という名前になります。
MDF で実装した任意 SSPI MBean ごとに、各メソッドを実装します。任意 SSPI MBean が継承するメソッドもすべて実装してください。
MDF にカスタム操作を含めた場合、メソッド スタブを使用してメソッドを実装します。
ファイルを保存します。
既存の MBean タイプの更新ですか。更新の場合は、次の手順に従ってください。
WebLogic MBeanMaker によって現在のメソッドの実装が上書きされないように、既存の MBean 実装ファイルを一時ディレクトリにコピーします。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
|
注意 : バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり ID アサーション プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。 |
任意 SSPI MBean を MDF に実装した場合は、次の手順に従います。
MBean 実装ファイルを見つけて開きます。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。 たとえば、SampleIdentityAsserter という名前の MDF の場合、編集される MBean 実装ファイルは SampleIdentityAsserterImpl.java という名前になります。
手順 1 で一時ディレクトリに保存した既存の MBean 実装ファイルを開きます。
既存の MBean 実装ファイルを、WebLogic MBeanMaker によって生成された MBean 実装ファイルと同期させます。
これには、メソッドの実装を既存の MBean 実装ファイルから新しく生成された MBean 実装ファイルにコピー (または、新しく生成された MBean 実装ファイルから既存の MBean 実装ファイルに新しいメソッドを追加) し、いずれの MBean 実装ファイルにも入っているメソッドのメソッド シグネチャへの変更が、使用する MBean 実装ファイルに反映されていることを確認するといった作業が必要です。
MDF を修正して元の MDF にはない任意 SSPI MBean を実装した場合は、各メソッドを実装します。任意 SSPI MBean が継承するメソッドもすべて実装してください。
MDF を変更して元の MDF にはないカスタム操作を含めた場合、メソッド スタブを使用してメソッドを実装します。
完成した、つまりすべてのメソッドを実装した MBean 実装ファイルを保存します。
この MBean 実装ファイルを、WebLogic MBeanMaker が MBean タイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順 3 で filesdir として指定したものです。 (手順 3 の結果として WebLogic MBeanMaker で生成された MBean 実装ファイルがオーバーライドされます)。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的について」で説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker を使用して SampleIdentityAsserter MDF を実行すると、SampleIdentityAsserterMBean.java という名前の MBean インタフェース ファイルが生成されます。
WebLogic MBeanMaker を使用して MDF を実行して中間ファイルを生成し、MBean 実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム ID アサーション プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。
カスタム ID アサーション プロバイダの MJF を作成するには、次の手順を行います。
新しい DOS シェルを作成します。
次のコマンドを入力します。
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを含む JAR ファイルを構築すべきであることを示し、jarfile は MJF の名前、filesdir は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所を示します。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。
|
注意 : カスタム セキュリティ プロバイダの JAR ファイルを作成する際には、一連の XML バインディング クラスと 1 つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム クラスと Oracle のカスタム クラスとの衝突を防ぐことができます。ネームスペースのデフォルトは vendor です。-targetNameSpace 引数を WebLogicMBeanMaker または関連する WLMBeanMaker ant タスクに渡すことで、このデフォルトを変更できます。既存の MJF を更新する場合は、単純に MJF を削除して再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御できます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false。このオプションは、-DMJF を使用しない場合には無視されます。 |
生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。
MBean タイプを WebLogic Server 環境にインストールするには、MJF をWL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。 これで、カスタム ID アサーション プロバイダが「デプロイ」されます。つまり、カスタム ID アサーション プロバイダが WebLogic Server Administration Console から管理できるようになります。
|
注意 : MBean タイプのインストール用のディレクトリは、デフォルトではWL_HOME\server\lib\mbeantypes ですが、初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\lib\mbeantypes からもロードできます。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用すれば、WebLogic Server が追加ディレクトリで MBean タイプを検索します。<dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server は最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードしてから、dirX および dirY にある有効なアーカイブをロードします。WebLogic Server に追加ディレクトリで MBean タイプを検索するように指示する際に JAVA セキュリティ マネージャを使用している場合は、weblogic.policy ファイルを更新して、MBean タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズガイド』の「Java セキュリティを使用しての WebLogic リソースの保護」を参照してください。 |
カスタム ID アサーション プロバイダをコンフィグレーションすることによって (「Administration Console によるカスタム ID アサーション プロバイダのコンフィグレーション」を参照)、MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。
カスタム ID アサーション プロバイダをコンフィグレーションするということは、そのカスタム ID アサーション プロバイダをセキュリティ レルムに追加するということです。追加されたカスタム ID アサーション プロバイダには、ID 断定サービスを必要とするアプリケーションからアクセスできます。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。
|
注意 : WebLogic Server Administration Console を使用してカスタム認可プロバイダをコンフィグレーションする手順は、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」で説明されています。 |
チャレンジ ID アサーション インタフェースは、複数のチャレンジ、応答メッセージ、および状態を必要とするチャレンジ応答スキーマをサポートします。チャレンジ ID アサーション プロバイダ インタフェースを使用すると、ID アサーション プロバイダは、Microsoft の Windows NT チャレンジ/応答 (NTLM) や SPNEGO (Simple and Protected GSS-API Negotiation) などのチャレンジ/応答認証メカニズムを採用した認証プロトコルをサポートできます。
WebLogic Security フレームワークを使用すると、カスタム認証プロバイダおよびカスタム ID アサーション プロバイダを利用できます。ただし、Java サーブレット API 2.3 の仕様により、認証プロセス時は、認証プロバイダとクライアントまたは他のサーバとの間の対話は制限されます。これにより、認証メカニズムは、サーブレット コンテナが提供する認証メカニズムと互換性のある基本、フォーム、証明書の形式に制限されます。
サーブレット認証フィルタ (「サーブレット認証フィルタ」を参照) には、アーキテクチャ依存の制限はほとんどありません。つまり、サーブレット認証フィルタは、サーブレット コンテナが提供する認証メカニズムに依存していません。認証プロセスを開始するコンテナの前にフィルタを呼び出せるようにすれば、セキュリティ レルムは、より柔軟な認証メカニズムを実装できます。たとえば、サーブレット認証フィルタを使用すると、認証用の SAML プロバイダ サイトにユーザをリダイレクトすることもできます。
サーブレット認証フィルタでは、ユーザの環境にチャレンジ/応答プロトコルを簡単に実装できます。フィルタを使用すると、ユーザのチャレンジ/応答メカニズムでチャレンジを完了するまで必要なだけチャレンジ ID アサーション インタフェースをループさせることができます。
サーブレット認証フィルタを使用すると、サーブレット コンテナと互換性のある認証メカニズムに制限されることなくチャレンジ/応答プロトコルを実装できます。ただし、サーブレット認証フィルタは、WebLogic Security フレームワークで提供されている認証環境の外側で機能するので、WebLogic Security フレームワークを利用してプロバイダのコンテキストを判別することはできません。また、サーブレット認証フィルタでは、API でチャレンジ回数が複数の ID アサーション プロセスを駆動させる必要があります。
weblogic.security.services.Authentication クラスが拡張され、サーブレット認証フィルタからの複数のチャレンジ/応答 ID アサーションが可能になりました。このクラスのメソッドおよびインタフェースでは、ChallengeIdentityAsserterV2 インタフェースと ProviderChallengeContext インタフェースに対してラッパーを利用できるので、サーブレット認証フィルタから呼び出すことができます。
これ以外に、WebLogic Security フレームワークのコンテキスト内でサーブレット認証フィルタから複数チャレンジ/応答ダイアログを実行する方法はドキュメント化されていません。サーブレット認証フィルタは、ChallengeIdentityAsserterV2 インタフェースおよび ProviderChallengeContext インタフェースを直接呼び出すことはできません。
そのため、ChallengeIdentityAsserterV2 インタフェースおよび ProviderChallengeContext インタフェースを実装し、weblogic.security.services.Authentication メソッドと AppChallengeContext インタフェースを使用してサーブレット認証フィルタからそれらのインタフェースを呼び出す必要があります。
ChallengeIdentityAsserterV2 インタフェースは、IdentityAsserterV2 SSPI を拡張します。IdentityAsserterV2 SSPI に加えて、ChallengeIdentityAsserterV2 インタフェースを実装する必要があります。
すべての IdentityAsserterV2 メソッドおよび以下のメソッドの実装を提供します。
assertChallengeIdentity
ProviderChallengeContext assertChallengeIdentity(String tokenType, Object token, ContextHandler handler)
提供されているクライアント トークンを使用し、場合によっては複数回のチャレンジでクライアント ID を確立します。このメソッドは、ProviderChallengeContext インタフェースの実装を返します。ProviderChallengeContext インタフェースには、チャレンジの状態を問い合わせる手段があります。
continueChallengeIdentity
void continueChallengeIdentity(ProviderChallengeContext context, String tokenType, Object token, ContextHandler handler)
提供されているプロバイダ コンテキストとクライアント トークンを使用して、クライアント ID の確立を続行します。
getChallengeToken
Object getChallengeToken(String type, ContextHandler handler)
このメソッドは、ID アサーション プロバイダのチャレンジ トークンを返します。
ProviderChallengeContext インタフェースには、チャレンジの状態を問い合わせる手段があります。ChallengeIdentityAsserterV2 インタフェースの assertChallengeIdentity メソッドおよび continueChallengeIdentity メソッドを使用し、コールバック ハンドラか、クライアントが応答する必要がある新しいチャレンジを返すことができます。
ProviderChallengeContext インタフェースを実装するには、以下のメソッドの実装を提供する必要があります。
getCallbackHandler
CallbackHandler getCallbackHandler()
このメソッドは、チャレンジ ID アサーションのコールバック ハンドラを返します。hasChallengeIdentityCompleted メソッドが true を返した場合にのみ、このメソッドを呼び出します。
getChallengeToken
Object getChallengeToken()
このメソッドは、チャレンジ ID アサーションのチャレンジ トークンを返します。hasChallengeIdentityCompleted メソッドが false を返した場合にのみ、このメソッドを呼び出します。
hasChallengeIdentityCompleted
boolean hasChallengeIdentityCompleted
このメソッドは、チャレンジ ID アサーションが完了したかどうかを返します。このメソッドは、チャレンジ ID アサーションが完了した場合は true、完了していない場合は false を返します。true の場合、呼び出し側は getCallbackHandler メソッドを使用する必要があります。false の場合、呼び出し側は getChallengeToken メソッドを使用する必要があります。
ChallengeIdentityAsserterV2 SSPI を直接呼び出すのではなく、サーブレット認証フィルタから以下の weblogic.security.services.Authentication メソッドを呼び出します。
assertChallengeIdentity
AppChallengeContext assertChallengeIdentity(String tokenType, Object token, AppContext appContext)
提供されているクライアント トークンを使用し、場合によっては複数回のチャレンジでクライアント ID を確立します。このメソッドは、チャレンジ ID アサーションのコンテキストを返します。この結果には、認証されたサブジェクトか、クライアントが応答する必要がある追加チャレンジが含まれる可能性があります。AppChallengeContext インタフェースには、チャレンジの状態を問い合わせる手段があります。
continueChallengeIdentity
void continueChallengeIdentity(AppChallengeContext context, String tokenType, Object token, AppContext appContext)
提供されているプロバイダ コンテキストとクライアント トークンを使用して、クライアント ID の確立を続行します。
getChallengeToken
Object getChallengeToken
このメソッドは、チャレンジ ID アサーションの初期チャレンジ トークンを返します。
ProviderChallengeContext インタフェースを直接呼び出すのではなく、サーブレット認証フィルタから以下の AppChallengeContext メソッドを呼び出します。
getAuthenticatedSubject
Subject getAuthenticatedSubject()
このメソッドは、チャレンジ ID アサーションで認証されたサブジェクトを返します。hasChallengeIdentityCompleted メソッドが true を返した場合にのみ、このメソッドを呼び出します。
getChallengeToken
Object getChallengeToken()
このメソッドは、チャレンジ ID アサーションのチャレンジ トークンを返します。hasChallengeIdentityCompleted メソッドが false を返した場合にのみ、このメソッドを呼び出します。
hasChallengeIdentityCompleted
boolean hasChallengeIdentityCompleted()
このメソッドは、チャレンジ ID アサーションが完了したかどうかを返します。このメソッドは、チャレンジ ID アサーションが完了した場合は true、完了していない場合は false を返します。true の場合、呼び出し側は getCallbackHandler メソッドを使用する必要があります。false の場合、呼び出し側は getChallengeToken メソッドを使用する必要があります。
以下のコード フローでは、サーブレット認証フィルタ (「サーブレット認証フィルタ」を参照) は、HTTP レベルの対話 (Authorization および WWW-Authenticate) を処理するとともに、weblogic.security.services.Authentication メソッドとインタフェースを呼び出してチャレンジ ID アサーション プロセスを駆動させる役割も果たしています。
ブラウザが要求を送信します。
フィルタは、要求を認識して Authorization ヘッダがないことを判別すると、weblogic.security.services.Authentication getChallengeToken メソッドを呼び出して初期トークンを取得し、WWW-Authenticate ネゴシエート ヘッダ付きの 401 応答を返します。
ブラウザは、WWW-Authenticate 付きの 401 を認識し、新しい要求と認証ネゴシエート トークン付きの応答を返します。
フィルタは、これを認識して weblogic.security.services.Authentication assertChallengeIdentity メソッドを呼び出します。assertChallengeIdentity は、トークンを入力として取り、アサーション プロセスで従う必要があるルールに従ってそれを処理し (たとえば、NTLM の場合は、トークン処理用に NTLM で要求されている処理を行います)、その処理が成功したかどうかを判別します。assertChallengeIdentity は、AppChallengeContext インタフェースの実装を返します。
フィルタは appChallengeContext hasChallengeCompleted メソッドを呼び出します。AppChallengeContext hasChallengeIdentityCompleted メソッドを使用して、チャレンジが完了したかどうかを確認します。たとえば、このメソッドは、コールバック ハンドラが null でない (つまりユーザ名が含まれている) かどうかを判別し、true を返すことができます。ここでは、false が返されるので、別のチャレンジをクライアントに発行する必要があります。フィルタは、次に AppChallengeContext getChallengeToken を呼び出し、チャレンジを再試行するためのトークンを取得します。
フィルタは、おそらくセッション属性などに AppChallengeContext を格納しています。
フィルタは、WWW-Authenticate ネゴシエートと新しいトークン付きの 401 応答を送信します。
ブラウザは、新しいチャレンジを認識し、Authorization ヘッダを付けて再び応答します。
フィルタは、これを認識して weblogic.security.services.Authentication continueChallengeIdentity メソッドを呼び出します。
フィルタは AppChallengeContext hasChallengeCompleted メソッドを呼び出します。false が返された場合は、別のチャレンジが用意されるので、AppChallengeContext getChallengeToken メソッドを呼び出して、チャレンジを再試行するためのトークンを取得します (以降、false の場合は同じ処理が繰り返されます)。true が返された場合、チャレンジは完了したことになり、フィルタは次に AppChallengeContext getAuthenticatedSubject メソッドを呼び出し、runAs(subject, request) を実行します。
