WebLogic Security サービスの開発
|
 |
 |
|
ID アサーション プロバイダは、ユーザまたはシステム プロセスがトークンを使用してそれぞれの ID を証明する特殊な形態の認証プロバイダです (つまり境界認証)。ID アサーション プロバイダ用の LoginModule を作成すれば、認証プロバイダの代わりに ID アサーション プロバイダを使用できます。また、認証プロバイダの LoginModule を使用する場合は、認証プロバイダに加えて ID アサーション プロバイダも使用できます。ID アサーション プロバイダは境界認証を有効にし、シングル サインオンをサポートします。
以下の節では、ID アサーション プロバイダの概念と機能、およびカスタム ID アサーション プロバイダの開発手順について説明します。
ID アサーション プロバイダを開発する前に、以下の概念を理解しておく必要があります。
LoginModule と一緒に用いると、ID アサーション プロバイダはシングル サインオンをサポートします。たとえば、ID アサーション プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザは何度もサインオンを求められることはありません。
ID アサーション プロバイダが使用する LoginModule は、以下のことが可能です。
単純認証の場合と違って (「認証プロセス」を参照)、ID アサーション プロバイダが使用する LoginModule は証明情報 (ユーザ名とパスワードなど) を検証しません (単にユーザが存在することを検証するだけです)。
注意 : LoginModule の詳細については、「LoginModule」を参照してください。
ID アサーション プロバイダは、ユーザまたはシステム プロセスの ID を断定するために使用する特定のトークン タイプをサポートするために開発します。ID アサーション プロバイダは複数のトークン タイプをサポートするように開発できますが、通常はただ 1 つの「アクティブ」なトークン タイプを検証するようにコンフィグレーションされます。同じトークン タイプを検証する複数の ID アサーション プロバイダを 1 つのセキュリティ レルムに組み込むことも可能ですが、実際に検証を行うのは 1 つの ID アサーション プロバイダだけです。
注意 : トークン タイプを「サポート」するということは、ID アサーション プロバイダの実行時クラス (IdentityAsserter SSPI 実装) がその assertIdentity メソッドでトークン タイプを検証できるということです。詳細については、「IdentityAsserter SSPI を実装する」を参照してください。
以下の節では、新しいトークン タイプを使用するための手順について説明します。
カスタム ID アサーション プロバイダを開発する場合には、新しいトークン タイプも作成できます。トークン タイプとは、文字列で表される 1 つのデータに過ぎません。どのようなトークン タイプを作成して使用するかは、完全にユーザに任されています。たとえば、現在、WebLogic ID アサーション プロバイダ用に定義されているトークン タイプは、X.509、CSI.PrincipalName、CSI.ITTAnonymous、CSI.X509CertChain、および CSI.DistinguishedName です。
新しいトークン タイプを作成するには、コード リスト 4-1 に示すとおり、新しい Java ファイルを作成し、String 型の変数として新しいトークン タイプを宣言します。PerimeterIdentityAsserterTokenTypes.java ファイルでは、Test 1、Test 2、および Test 3 というトークン タイプの名前が文字列として定義されています。
コード リスト 4-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";
}
注意 : 1 つの新しいトークン タイプを定義するだけの場合は、コード リスト 4-4 で示されているように ID アサーション プロバイダの実行時クラスで行うこともできます。
カスタム ID アサーション プロバイダをコンフィグレーションする場合には (「Administration Console を使用してカスタム ID アサーション プロバイダをコンフィグレーションする」を参照)、ID アサーション プロバイダのサポートするトークン タイプのリストが [タイプ] フィールドに表示されます。図 4-1 に示すとおり、サポート タイプの 1 つを、アクティブなタイプのフィールドに入力できます。
図 4-1 サンプル ID アサーション プロバイダのコンフィグレーション
[タイプ] フィールドの内容は、カスタム ID アサーション プロバイダの MBean タイプを生成するために使用する MBean 定義ファイル (MDF) の SupportedTypes 属性から取得します。サンプル ID アサーション プロバイダからの例が、コード リスト 4-2 で示されています。 (MDF および MBean タイプの詳細については、「WebLogic MBeanMaker を使用して MBean タイプを生成する」を参照)。
コード リスト 4-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 アサーション プロバイダからの例が、コード リスト 4-3 で示されています。
コード リスト 4-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 では、IIOP (Internet Inter-ORB) (GIOP バージョン 1.2) および CORBA CSIv2 (Common Secure Interoperability version 2) 仕様に基づいた EJB (Enterprise JavaBean) 相互運用性プロトコルをサポートしています。WebLogic Server で CSIv2 をサポートすることにより、以下のことが可能になります。
注意 : 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 の利用については、「Common Secure Interoperability Version 2 (CSIv2)」を参照してください。JAAS LoginModule の詳細については、「LoginModule」を参照してください。
境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します (これは「認証プロセス」で説明されている認証のタイプとは対照的です。その認証では、WebLogic Server がユーザ名とパスワードを通じて信頼を確立します)。ID アサーション プロバイダは、次に示す境界認証プロセスの一部として使用されます (図 4-2 を参照):
CallbackHandler を通じて送信され、コンフィグレーションされている各認証プロバイダの LoginModule に渡されて、サブジェクト内に適切なプリンシパルを格納できるようになります。As 図 4-2 でも示されているように、境界認証では 「認証プロセス」で説明されている認証プロセスと同じ構成要素が必要ですが、ID アサーション プロバイダも追加されます。
WebLogic ID アサーション プロバイダでは、X509 証明書を使用した証明書認証および CSIv2 (CORBA Common Secure Interoperability version 2) ID アサーションがサポートされています。
WebLogic ID アサーション プロバイダはトークン タイプを検証し、X509 デジタル証明書と X501 識別名を WebLogic ユーザ名にマップします。また、CSIv2 ID アサーションに使用する信頼性のあるクライアント プリンシパルのリストも指定します。ワイルドカード文字 (*) を使用すると、すべてのプリンシパルに信頼性があると指定できます。クライアントが信頼性のあるクライアント プリンシパルのリストにない場合は、CSIv2 ID アサーションが失敗し、呼び出しが拒否されます。
注意 : X.501 および X.509 証明書に対して WebLogic ID アサーション プロバイダを使用するには、WebLogic Server 製品に付属しているデフォルトのユーザ名マッパー (weblogic.security.providers.authentication.) を使用するか、または独自の
DefaultUserNameMapperImplweblogic.security.providers.authentication.UserNameMapper インタフェースの実装を用意するかのいずれかの方法があります。このインタフェースは、必要に応じた方式に従って、X.509 証明書を WebLogic Server のユーザ名にマップします。また、このインタフェースを使用して X.501 識別名をユーザ名にマップすることもできます。Administration Console を使用して ID アサーション プロバイダをコンフィグレーションするときに、このインタフェースの実装を指定します。詳細については、『WebLogic Security の管理』の「ユーザ名マッパーのコンフィグレーション」および「カスタム ユーザ名マッパーのコンフィグレーション」を参照してください。
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 がトークンとして使用される場合に使用します。 追加的な ID アサーション タスクを実行したい場合、または新しいトークン タイプを作成したい場合は、カスタム ID アサーション プロバイダを開発する必要があります。
WebLogic ID アサーション プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム ID アサーション プロバイダを開発することができます。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム ID アサーション プロバイダの実行時クラスを作成します。
注意 : カスタム ID アサーション プロバイダ用に別の LoginModule を作成する (認証プロバイダの LoginModule を使用しない) 場合は、JAAS LoginModule インタフェースも実装する必要があります (「JAAS LoginModule インタフェースを実装する」を参照)。
カスタム ID アサーション プロバイダの実行時クラスの作成例については、「例 : サンプル ID アサーション プロバイダの実行時クラスの作成」を参照してください。
AuthenticationProvider SSPI を実装するには、「「Provider」SSPI の目的を理解する」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getLoginModuleConfiguration メソッドは、認証プロバイダの関連付けられた LoginModule に関する情報を取得します。その情報は、AppConfigurationEntry として返されます。AppConfigurationEntry は、LoginModule のクラス名、認証プロバイダの関連する MBean を通じて渡された LoginModule の制御フラグ、および他のコンフィグレーション情報を LoginModule に渡すことを可能にする LoginModule のコンフィグレーション オプション マップの格納された JAAS (Java Authentication and Authorization Service) クラスです。
AppConfigurationEntry クラス (javax.security.auth.login パッケージ) と LoginModule の制御フラグ オプションの詳細については、Java 2 Enterprise Edition, v1.4.1 API 仕様 Javadoc の「AppConfigurationEntry クラス」および「Configuration クラス」を参照してください。LoginModule の詳細については、「LoginModule」を参照してください。セキュリティ プロバイダと MBean の詳細については、「MBean タイプが必要な理由を理解する」を参照してください。
public AppConfigurationEntry getAssertionModuleConfiguration()
getAssertionModuleConfiguration メソッドは、ID アサーション プロバイダの関連付けられた LoginModule に関する情報を取得します。その情報は、AppConfigurationEntry として返されます。AppConfigurationEntry は、LoginModule のクラス名、ID アサーション プロバイダの関連する MBean を通じて渡された LoginModule の制御フラグ、および他のコンフィグレーション情報を LoginModule に渡すことを可能にする LoginModule のコンフィグレーション オプション マップの格納された JAAS クラスです。
注意 : ID アサーション プロバイダの assertIdentity() メソッドは、ID アサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModule は呼び出されないことがあります。-Dweblogic.security.identityAssertionTTL フラグを使うと、この動作を左右する (たとえば、5 分というデフォルト TTL を変更する、またはフラグを -1 に設定してキャッシュを無効にする) ことができます。
トークンが有効なだけでなく、ユーザも引き続き有効であること (ユーザが削除されていないことなど) を確認するのは、ID アサーション プロバイダの役割です。
getPrincipalValidator メソッドは、プリンシパル検証プロバイダの実行時クラス (PrincipalValidator SSPI 実装) の参照を取得します。詳細については、「プリンシパル検証プロバイダ」を参照してください。
getIdentityAsserter メソッドは、ID アサーション プロバイダの実行時クラス (IdentityAsserter SSPI 実装) の参照を取得します。詳細については、「IdentityAsserter SSPI を実装する」を参照してください。
注意 : ID アサーション プロバイダ用の LoginModule が既存の認証プロバイダ用の LoginModule と同じである場合、ID アサーション プロバイダ用の AuthenticationProvider SSPI 内のメソッドの実装 (getIdentityAsserter メソッドを除く) は null を返す場合があります。コード リスト 4-4 に例を示します。
AuthenticationProvider SSPI と上記メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」 を参照してください。
IdentityAsserter SSPI を実装する際には、以下のメソッドの実装を提供する必要があります。
public CallbackHandler assertIdentity(String type, Object token) throws IdentityAssertionException;
assertIdentity メソッドは、提供されたトークンの ID 情報に基づいて ID を断定します。言い換えれば、このメソッドの目的は、現時点で「信頼性のない」トークンがあれば、それを信頼性のあるクライアント プリンシパルに照らし合わせて検証することです。type パラメータは、ID アサーション (ID の断定) に使用するトークン タイプを表します。ID アサーション タイプには大文字/小文字の区別がないことに注意してください。また、token パラメータには実際の ID 情報が格納されています。assertIdentity から返される CallbackHandler は、断定されたユーザ名を格納する必要があり、プリンシパル マッピングを行うためにコンフィグレーションされているすべての認証プロバイダの LoginModule に渡されます。CallbackHandler が null の場合には、匿名ユーザを使用することを意味します。
注意 : 8.1 SP05 より前のバージョンの 8.1 では、コールバック ハンドラが JAAS NameCallback をサポートしていない場合、キャッシュされた ID をルックアップしようとすると、ID アサーションの呼び出しが失敗します。これは、コールバック ハンドラから返される名前が、サブジェクト キャッシュ内の関連付けられたサブジェクトを検索するためのキーとして使用されるからです。つまり、JAAS NameCallback をサポートしていないコールバック ハンドラは、サブジェクトを見つけられない名前キーを返します。
CallbackHandler は、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟な JAAS 規格です。CallbackHandler の詳細については、Java 2 Enterprise Edition, v1.4.1 API 仕様 Javadoc を参照して CallbackHandler インタフェースを調べてください。
注意 : ID アサーション プロバイダの assertIdentity() メソッドは、ID アサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModule は呼び出されないことがあります。-Dweblogic.security.identityAssertionTTL フラグを使うと、この動作を左右する (たとえば、5 分というデフォルト TTL を変更する、またはフラグを 0 に設定してキャッシュを無効にする) ことができます。
トークンが有効なだけでなく、ユーザも引き続き有効であること (ユーザが削除されていないことなど) を確認するのは、ID アサーション プロバイダの役割です。
IdentityAsserter SSPI と上記メソッドの詳細については、「WebLogic Server 8.1 API リファレンス Javadoc」 を参照してください。
コード リスト 4-4 は、サンプル ID アサーション プロバイダの実行時クラスである SampleIdentityAsserterProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。
initialize、getDescription、および shutdown という SecurityProvider インタフェースから継承した 3 つのメソッド (「「Provider」SSPI の目的を理解する」を参照)getLoginModuleConfiguration、getAssertionModuleConfiguration、getPrincipalValidator、および getIdentityAsserter という AuthenticationProvider SSPI の 4 つのメソッド (「AuthenticationProvider SSPI を実装する」を参照)assertIdentity という IdentityAsserter SSPI のメソッド (「IdentityAsserter SSPI を実装する」を参照)注意 : コード リスト 4-4 の太字のコードは、クラス宣言とメソッド シグネチャを示しています。
コード リスト 4-4 SampleIdentityAsserterProviderImpl.java
package examples.security.providers.identityassertion;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.AppConfigurationEntry;
import weblogic.management.security.ProviderMBean;
import weblogic.security.spi.AuthenticationProvider;
import weblogic.security.spi.IdentityAsserter;
import weblogic.security.spi.IdentityAssertionException;
import weblogic.security.spi.PrincipalValidator;
import weblogic.security.spi.SecurityServices;
public final class SampleIdentityAsserterProviderImpl implements AuthenticationProvider, IdentityAsserter
{
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("SampleIdentityAsserterProviderImpl.initialize");
SampleIdentityAsserterMBean myMBean = (SampleIdentityAsserterMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SampleIdentityAsserterProviderImpl.shutdown");
}
public AppConfigurationEntry getLoginModuleConfiguration()
{
return null;
}
public AppConfigurationEntry getAssertionModuleConfiguration()
{
return null;
}
public PrincipalValidator getPrincipalValidator()
{
return null;
}
public IdentityAsserter getIdentityAsserter()
{
return this;
}
public CallbackHandler assertIdentity(String type, Object token) throws
IdentityAssertionException
{
System.out.println("SampleIdentityAsserterProviderImpl.assertIdentity");
System.out.println("\tType\t\t= " + type);
System.out.println("\tToken\t\t= " + token);
if (!(TOKEN_TYPE.equals(type))) {
String error = "SampleIdentityAsserter received unknown token type \""
+ type + "\"."+ " Expected " + TOKEN_TYPE;
System.out.println("\tError: " + error);
throw new IdentityAssertionException(error);
}
if (!(token instanceof byte[])) {
String error = "SampleIdentityAsserter 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 = "SampleIdentityAsserter 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 = "SampleIdentityAsserter 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 SampleCallbackHandlerImpl(userName);
}
}
コード リスト 4-5 は、SampleIdentityAsserterProviderImpl.java 実行時クラスとともに使用する CallbackHandler のサンプル実装を示しています。この CallbackHandler の実装は、認証プロバイダの LoginModule にユーザ名を送り返すために使用します。
注意 : 8.1 SP05 より前のバージョンの 8.1 では、コールバック ハンドラが JAAS NameCallback をサポートしていない場合、キャッシュされた ID をルックアップしようとすると、ID アサーションの呼び出しが失敗します。これは、コールバック ハンドラから返される名前が、サブジェクト キャッシュ内の関連付けられたサブジェクトを検索するためのキーとして使用されるからです。つまり、JAAS NameCallback をサポートしていないコールバック ハンドラは、サブジェクトを見つけられない名前キーを返します。
コード リスト 4-5 SampleCallbackHandlerImpl.java
package examples.security.providers.identityassertion;
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 SampleCallbackHandler implements CallbackHandler
{
private String userName;
/*package*/ SampleCallbackHandlerImpl(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 タイプを作成します。
注意 : これらの手順の実行方法は、いくつかのサンプル セキュリティ プロバイダ (dev2dev Web サイトの「Code Samples: WebLogic Server」で入手可能) に示されています。
この節で説明する手順はすべて、Windows 環境での作業を想定しています。
MBean 定義ファイル (MDF) を作成するには、次の手順に従います。
注意 : MDF 要素の構文についての完全なリファレンスは、「MBean 定義ファイル (MDF) 要素の構文」に収められています。
MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。
MBean タイプの生成手順は、カスタム ID アサーション プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム ID アサーション プロバイダの MDF に任意 SSPI MBean もカスタム操作も実装しない場合、次の手順に従います。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。filesdir で指定された場所にファイルがすでに存在する場合には、既存のファイルが上書きされることが通知され確認を求められます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり ID アサーション プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
カスタム ID アサーション プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり ID アサーション プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、SampleIdentityAsserter という名前の MDF の場合、編集される MBean 実装ファイルは SampleIdentityAsserterImpl.java という名前になります。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。
-DMDF フラグで指定された xml ファイルと同じディレクトリに WL_HOME\server\lib\commo.dtd をコピーします。
xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。
注意 : WebLogic MBeanMaker では MDF を一度に 1 つ処理します。そのため、MDF が複数ある (つまり ID アサーション プロバイダが複数ある) 場合には、このプロセスを繰り返す必要があります。
WebLogic MBeanMaker によって生成される MBean 実装ファイルには、MBeanNameImpl.java という名前が付けられます。たとえば、SampleIdentityAsserter という名前の MDF の場合、編集される MBean 実装ファイルは SampleIdentityAsserterImpl.java という名前になります。
これには、メソッドの実装を既存の MBean 実装ファイルから新しく生成された MBean 実装ファイルにコピー (または、新しく生成された MBean 実装ファイルから既存の MBean 実装ファイルに新しいメソッドを追加) し、いずれの MBean 実装ファイルにも入っているメソッドのメソッド シグネチャへの変更が、使用する MBean 実装ファイルに反映されていることを確認するといった作業が必要です。
MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的を理解する」で説明されているように、これは initialize メソッドで使用するのが一般的です。
WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker を使用して SampleIdentityAsserter MDF を実行すると、MBean インタフェース ファイルの名前が SampleIdentityAsserterMBean.java になります。
WebLogic MBeanMaker を使用して MDF を実行して中間ファイルを生成し、MBean 実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム ID アサーション プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。
カスタム ID アサーション プロバイダの MJF を作成するには、次の手順を行います。
WL_HOME\server\lib\weblogic.jarWL_HOME\server\lib\mbeantypes\wlManagement.jarJAVA_HOME\..\lib\tools.jar-Dfiles フラグで指定する filedirjava -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを含む JAR ファイルを構築すべきであることを示し、jarfile は MJF の名前、filesdir は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所を示します。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。
注意 : 既存の MJF を更新する場合は、MJF をいったん削除してから再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御することができます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false です。このオプションは、-DMJF を使用しない場合には無視されます。
生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。
MBean タイプを WebLogic Server 環境にインストールするには、MJF を WebLogic Server の WL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。これで、カスタム ID アサーション プロバイダが「デプロイ」されます。つまり、カスタム ID アサーション プロバイダが WebLogic Server Administration Console から管理できるようになります。
注意 : MBean タイプをインストールするデフォルトのディレクトリは、WL_HOME\server\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 タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『WebLogic Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
カスタム ID アサーション プロバイダをコンフィグレーションすることによって (「Administration Console を使用してカスタム ID アサーション プロバイダをコンフィグレーションする」を参照) MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。詳細については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」の「セキュリティ データのバックアップ」を参照してください。
カスタム ID アサーション プロバイダをコンフィグレーションするということは、そのカスタム ID アサーション プロバイダをセキュリティ レルムに追加するということです。追加されたカスタム ID アサーション プロバイダには、ID 断定サービスを必要とするアプリケーションからアクセスできます。
カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。
注意 : WebLogic Server Administration Console を使用してカスタム ID アサーション プロバイダをコンフィグレーションする手順は、『WebLogic Security の管理』の「カスタム セキュリティ プロバイダのコンフィグレーション」で説明されています。
|
|
|