Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 12c 12c (12.2.1.3.0) E90323-01 |
|
![]() 前 |
![]() 次 |
IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDをアサートする特殊な形態(つまり境界認証)の認証プロバイダです。IDアサーション・プロバイダは、境界認証を可能にし、シングル・サインオンをサポートします。IDアサーション・プロバイダ用のLoginModuleを作成すれば、認証プロバイダのかわりにIDアサーション・プロバイダを使用できます。また、認証プロバイダのLoginModuleを使用する場合は、認証プロバイダに加えてIDアサーション・プロバイダも使用できます。
IDアサーション・プロバイダを認証プロバイダとは別に構成できるようにするには、2つのプロバイダを作成します。IDアサーション・プロバイダと認証プロバイダが独立して機能できない場合は、1つのプロバイダを作成します。
この章の内容は次のとおりです。
IDアサーション・プロバイダを開発する前に、次の概念を理解しておく必要があります。
LoginModuleと一緒に用いると、IDアサーション・プロバイダはシングル・サインオンをサポートします。たとえば、IDアサーション・プロバイダは、デジタル証明書からトークンを生成できます。そのトークンはシステム内で順に回すことができ、ユーザーが何度もサインオンを求められないようにすることができます。
IDアサーション・プロバイダが使用するLoginModuleでは、次のことが可能です。
開発したカスタム認証プロバイダの一部となります。詳細は、「認証プロバイダ」を参照してください。
Oracleが開発しWebLogic Serverと一緒にパッケージ化したWebLogic認証プロバイダの一部になります。「カスタム認証プロバイダを開発する必要があるか」を参照してください。
サード・パーティのセキュリティ・ベンダーの認証プロバイダの一部となります。
単純認証の場合とは異なり(「認証プロセス」を参照)、IDアサーション・プロバイダが使用するLoginModuleは証明情報(ユーザー名やパスワードなど)を検証しません(単にユーザーが存在することを検証するだけです)。
この構成のLoginModuleは以下の処理を行う必要があります。
WLSGroup型などの必須のプリンシパルをサブジェクトに格納します。
ユーザーがログインのための十分な証明を提供していると見なし、パスワードなどの証明データを要求しません。
「AuthenticationProviderV2 SSPIの実装」の説明に従って、カスタム認証プロバイダにAuthenticationProviderV2.getAssertionModuleConfiguration
メソッドを実装する必要がありますこのメソッドは、X.509証明書を使用している場合などに、IDアサーションがデプロイメント記述子のrun-asタグを処理するために呼び出されます。他のシングル・サインオン方式でも、このメソッドを使用します。
注意:
「LoginModules」を参照してください。
IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスのIDをアサートするために使用する特定のトークン・タイプをサポートするために開発します。IDアサーション・プロバイダは複数のトークン・タイプをサポートするように開発できますが、通常はただ1つのアクティブ
なトークン・タイプを検証するように構成されます。同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを1つのセキュリティ・レルムに組み込むことも可能ですが、実際に検証を行うのは1つのIDアサーション・プロバイダだけです。
注意:
トークン・タイプをサポートする
ということは、IDアサーション・プロバイダのランタイム・クラス(IdentityAsserter SSPI実装)がそのassertIdentityメソッドでトークン・タイプを検証できるということです。「IdentityAsserterV2 SSPIの実装」を参照してください。
以下の節では、新しいトークン・タイプを使用するための手順について説明します。
カスタムIDアサーション・プロバイダを開発する場合には、新しいトークン・タイプも作成できます。トークン・タイプとは、文字列で表される1つのデータに過ぎません。どのようなトークン・タイプを作成して使用するかは、完全にユーザーに任されています。たとえば、現在WebLogic IDアサーション・プロバイダ用に定義されているトークンには、AuthenticatedUser
、X.509
、CSI.PrincipalName
、CSI.ITTAnonymous
、CSI.X509CertChain
、CSI.DistinguishedName
、wsse:PasswordDigest
など、様々なタイプがあります。
新しいトークン・タイプを作成するには、例5-1
に示すとおり、新しいJavaファイルを作成し、String型の変数として新しいトークン・タイプを宣言します。PerimeterIdentityAsserterTokenTypes.java
ファイルでは、Test 1
、Test 2
、およびTest 3
というトークン・タイプの名前が文字列として定義されています。
注意:
新しいトークン・タイプを1つだけ定義する場合は、例5-4で示されているようにIDアサーション・プロバイダのランタイム・クラスで行うこともできます。
例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アサーション・プロバイダを構成する場合(「管理コンソールによるカスタムIDアサーション・プロバイダの構成」を参照)、IDアサーション・プロバイダのサポートするトークン・タイプのリストが「サポートされている種類」フィールドに表示されます。図5-1に示すとおり、サポートされているタイプの1つを「アクティブな種類」フィールドに入力します。
「サポートされている種類」フィールドの内容は、カスタムIDアサーション・プロバイダのMBeanタイプを生成するために使用するMBean定義ファイル(MDF)のSupportedTypes
属性から取得されます。サンプルIDアサーション・プロバイダの例を例5-2に示します。(「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管理コンソールで手動設定する必要がなくなります。サンプル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アサーション・プロバイダの構成の詳細は、「管理コンソールによるカスタムIDアサーション・プロバイダの構成」を参照してください。
IDアサーション・プロバイダは、境界認証のためにJavaクライアントからサーブレットにトークンを渡すことができます。トークンは、HTTPヘッダー、Cookie、SSL証明書などのメカニズムを用いて渡すことができます。たとえば、HTTPヘッダーを使用すれば、Base64でコード化された文字列(バイナリ・データの送信が可能)をサーブレットに送信することができます。この文字列の値は、ユーザー名などのユーザーのIDを表す文字列です。境界認証に使用されるIDアサーション・プロバイダは、その文字列を受け取り、そこからユーザー名を抽出できます。
トークンがHTTPヘッダーまたはCookieを通じて渡される場合には、そのトークンはヘッダーまたはCookieの名前に等しく、リソース・コンテナはWebLogicセキュリティ・フレームワークの認証を処理するパートにトークンを渡します。WebLogicセキュリティ・フレームワークは、そのトークンをそのまま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 (Enterprise JavaBean)相互運用性プロトコルをサポートしています。WebLogic ServerでCSIv2をサポートすることにより、以下のことが可能になります。
Java EE (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実装は、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
パッケージに格納されています。
CSIv2は以下のように動作します。
IOR (Interoperable Object Reference)へのセキュリティ拡張機能の作成時に、WebLogic Serverは、CORBAオブジェクトでサポートされるセキュリティ・メカニズムを識別するタグ付きコンポーネントを追加します。このタグ付きコンポーネントには、トランスポート情報、クライアント認証情報、およびID証明トークン/認可トークン情報が入っています。
クライアントは、IOR内のセキュリティ・メカニズムを評価し、サーバーが必要とするオプションをサポートするメカニズムを選択します。
クライアントはSASプロトコルを用いて、WebLogic Serverとのセキュリティ・コンテキストを確立します。SASプロトコルはリクエストとレスポンスからなるサービス・コンテキスト内に含まれるメッセージを定義します。コンテキストはステートフルでもステートレスでもかまいません。
CSIv2の利用については、Oracle WebLogic Serverのセキュリティの理解のCommon Secure Interoperability Version 2を参照してください。「LoginModules」を参照してください。
境界認証では、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識別名をユーザー名にマップすることもできます。WebLogic Server管理コンソールを使用して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形式がトークンとして使用される場合に使用します。
SAML2_ASSERTION_DOM_TYPE
- SAML2 DOM要素がトークンとして使用される場合に使用します。
SAML2_ASSERTION_TYPE
- SAML2文字列XML形式がトークンとして使用される場合に使用します。
SAML_SSO_CREDENTIAL_TYPE
- TARGETパラメータで構成されるSAML文字列がアサーション自体と連結され、トークンとして使用される場合に使用します。
WSSE_PASSWORD_DIGEST_TYPE
- パスワード・ダイジェストのパスワード・タイプを持つユーザー名トークンがトークンとして使用される場合に使用します。
WWW_AUTHENTICATE_NEGOTIATE
- SPNEGO内部トークンがトークンとして使用される場合に使用します。
追加的なIDアサーション・タスクを実行したい場合、または新しいトークン・タイプを作成したい場合は、カスタムIDアサーション・プロバイダを開発する必要があります。
WebLogic IDアサーション・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタムIDアサーション・プロバイダを開発することができます。
「WebLogic MBeanMakerを使用してMBeanタイプを生成する」で説明されている手順を実行してカスタムIDアサーション・プロバイダのMBeanタイプを生成
「チャレンジ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
クラスとLoginModulesの制御フラグ・オプションの詳細は、AppConfigurationEntryクラスに関する項(http://docs.oracle.com/javase/8/docs/api/javax/security/auth/login/AppConfigurationEntry.html
)およびConfigurationクラスに関する項(http://docs.oracle.com/javase/8/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と前述のメソッドの詳細は、Oracle WebLogic Server Java APIリファレンスを参照してください。
注意:
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
の詳細は、CallbackHandlerインタフェースに関する項(http://docs.oracle.com/javase/8/docs/api/javax/security/auth/callback/CallbackHandler.html
)を参照してください。
注意:
IDアサーション・プロバイダのassertIdentity()
メソッドは、IDアサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModuleは呼び出されないことがあります。-Dweblogic.security.identityAssertionTTL
フラグを使うと、この動作を変更する(たとえば、5分というデフォルトTTLを変更する、またはフラグを -1に設定してキャッシュを無効にする)ことができます。
トークンが有効なだけでなく、ユーザーも引続き有効であること(ユーザーが削除されていないことなど)を確認するのは、IDアサーション・プロバイダの役割です。
IdentityAsserterV2
SSPIと前述のメソッドの詳細は、Oracle WebLogic Server Java APIリファレンスを参照してください。
例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の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。
例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); } } }
カスタムIDアサーション・プロバイダを構成するということは、そのカスタムIDアサーション・プロバイダをセキュリティ・レルムに追加するということです。追加されたカスタムIDアサーション・プロバイダには、IDアサーション・サービスを必要とするアプリケーションからアクセスできます。
カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。
注意:
WebLogic Server管理コンソールを使用してカスタムのIDアサーション・プロバイダを構成する手順は、Oracle WebLogic Serverセキュリティの管理のWebLogicセキュリティ・プロバイダの構成を参照してください。
チャレンジIDアサーション・インタフェースは、複数のチャレンジ、レスポンス・メッセージ、および状態を必要とするチャレンジ・レスポンス・スキームをサポートします。チャレンジIDアサーション・プロバイダ・インタフェースを使用すると、IDアサーション・プロバイダは、MicrosoftのWindows NTチャレンジ/レスポンス(NTLM)やSPNEGO (Simple and Protected GSS-API Negotiation)などのチャレンジ/レスポンス認証メカニズムを採用した認証プロトコルをサポートできます。
WebLogicセキュリティ・フレームワークを使用すると、カスタム認証プロバイダおよびカスタムIDアサーション・プロバイダを利用できます。ただし、JavaサーブレットAPI 2.3の仕様により、認証プロセス時は、認証プロバイダとクライアントまたは他のサーバーとの間の対話はアーキテクチャで制限されます。これにより、認証メカニズムは、サーブレット・コンテナが提供する認証メカニズムと互換性のある基本、フォーム、証明書の形式に制限されます。
サーブレット認証フィルタ(「サーブレット認証フィルタ」を参照)には、アーキテクチャ依存の制限はほとんどありません。つまり、サーブレット認証フィルタは、サーブレット・コンテナが提供する認証メカニズムに依存していません。認証プロセスを開始するコンテナの前にフィルタを呼び出せるようにすれば、セキュリティ・レルムは、より柔軟な認証メカニズムを実装できます。たとえば、サーブレット認証フィルタを使用すると、認証用のSAMLプロバイダ・サイトにユーザーをリダイレクトできます。
サーブレット認証フィルタでは、ユーザーの環境にチャレンジ/レスポンス・プロトコルを簡単に実装できます。フィルタを使用すると、ユーザーのチャレンジ/レスポンス・メカニズムでチャレンジを完了するまで必要なだけチャレンジIDアサーション・インタフェースをループさせることができます。
サーブレット認証フィルタを使用すると、サーブレット・コンテナと互換性のある認証メカニズムに制限されることなくチャレンジ/レスポンス・プロトコルを実装できます。ただし、サーブレット認証フィルタは、セキュリティ・フレームワークで提供されている認証環境の外側で機能するので、セキュリティ・フレームワークを利用してプロバイダのコンテキストを判別することはできません。また、サーブレット認証フィルタでは、APIでチャレンジ回数が複数のIDアサーション・プロセスを駆動させる必要があります。
weblogic.security.services.Authentication
クラスが拡張され、サーブレット認証フィルタからの複数のチャレンジ/レスポンスIDアサーションが可能になりました。メソッドおよびインタフェースでは、ChallengeIdentityAsserterV2
インタフェースとProviderChallengeContext
インタフェースのラッパーが提供されるので、サーブレット認証フィルタから呼び出すことができます。
これ以外に、セキュリティ・フレームワークのコンテキスト内でサーブレット認証フィルタから複数のチャレンジ/レスポンス・ダイアログを実行する方法はドキュメント化されていません。サーブレット認証フィルタは、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)を実行します。