| Oracle® Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース2 (11.1.2.1.0) B69536-05 |
|
 前 |
 次 |
アイデンティティ・コネクタは、Oracle Identity Managerをアプリケーション、ディレクトリおよびデータベースの外部ストアとリンクする目的で開発されたコンポーネントです。Oracle Identity Managerでは、Identity Connector Framework (ICF)を使用してアイデンティティ・コネクタを開発および構築できます。ICFにより、Oracle Identity Managerが接続先の他のアプリケーションから切り離されます。そのため、アイデンティティ・コネクタを構築およびテストしてから、Oracle Identity Managerと統合できます。この章は、概念情報およびコード例を示す次の項で構成されます。
|
注意: 以前のリリースのOracle Identity Managerでは、他のオプションによってアイデンティティ・コネクタを構築していました。これらのオプションも引き続きサポートされていますが、ICFを使用して新しいアイデンティティ・コネクタを構築することをお薦めします。 |
ICFには次の利点があります。
単一のプラットフォーム: アイデンティティ・コネクタは、Oracle Identity ManagerおよびOracle Waveset (OW)間で共有されており、OIMおよびOWの両方に単一のコネクタを使用して外部アイデンティティ対応のアプリケーションと通信できるように、同じプラットフォーム上に構築されています。
単純なインストール: ICFは、インストール中の手動の構成として、コネクタ・ファイルおよびコード・ファイルのコピーがICFによって自動的に処理されるなど、単純なインストールを提供します。
設計上ステートレス: アイデンティティ・コネクタは、設計上ステートレスです。アイデンティティ・コネクタには何も格納されません。コール側アプリケーションからコネクタに構成値(ターゲット・アプリケーションに接続するために必要な情報を含む)が提供されます。これは、アイデンティティ・コネクタがステートレスであるため、各バンドル実装はできるだけ単純な状態に保たれ、コール側アプリケーションの実装との結合も回避されます。
ICF共通: ICFでは、OIMのICFベースのコネクタに共通のコネクタ統合レイヤーを提供し、ICF共通を開発するための開発作業は必要ありません。
リモート実行: ICFでは、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行がサポートされています。
JVMの独立性: リモートICFにより、JVMの独立性が提供され、異なるホストでのJavaコネクタの実行によるJVM競合を防止します。
再利用: 将来的に、他の製品でアイデンティティ・コネクタを再利用できます。
アイデンティティ・コネクタにより、Oracle Identity Managerが企業内のターゲット・システムでユーザーのプロビジョニングおよびリコンシリエーションの処理を実行できるようになります。ICFを使用すると、Oracle Identity Managerなどのコール側アプリケーションがコネクタの実装から切り離されます。同様に、コネクタの実装がコール側アプリケーションから切り離されます。同じコネクタ実装を複数の異なるコール側アプリケーションと連携させることができます。図9-1では、Oracle Identity Managerとターゲット・システムの間にICF APIおよびSPIを配置することによって、これを実現しています。
API実装では、必ず、SPI Search処理によって返された結果が後処理されます。コネクタ・バンドルによってすべてのフィルタ・タイプが実装されるわけではない場合、またはフィルタ・タイプがすべての属性に対して適切に実装されるわけではない場合、これがSPI実装の二重チェックになります。SPI Searchの実装によって、指定したタイプのすべてのオブジェクトが返される場合、API実装によって、指定したフィルタに一致しないすべてのオブジェクトが破棄されます。API実装における後処理は処理時間とネットワーク帯域幅の面でコスト高になるため、ターゲット・アプリケーションでネイティブにサポートできるすべてのタイプのフィルタ(検索述語や論理演算子)を各コネクタ・バンドルでサポートすると、より効率的です。詳細は、「共通クラス」のFilterTranslatorを参照してください。
図9-1では、コール側アプリケーションはICF APIのみを認識しています。ICF APIでは各コネクタ・バンドルに専用のクラスローダーが割り当てられるため、コネクタ・バンドル(SPI)の実装におけるクラスやライブラリにコール側アプリケーションは公開されません。バンドル・クラスローダーは、バンドル間を確実に分離するだけでなく、バンドルされたライブラリを対象のコネクタ・バンドルのみに公開して、依存関係による競合を防止する役割も担います。
図9-2に、ICFの下位互換性を示します。新しいバンドルをデプロイしても、既存のバンドルには影響しません。また、新しいバージョンのICFには、一般に既存のバンドルとの下位互換性があります。したがって、すべてのコネクタは、新しいバージョンのフレームワークで作業する必要があります。
図9-3は、ICFのデプロイメント方法を示しています。フレームワークでは、LCMでのコネクタのクローニングをサポートしており、同じターゲットの複数のバージョンをサポートします。また、フレームワークは接続プーリングもサポートします。
図9-4は、リモート・システムにインストールされたフレームワークを示しています。これにより、ターゲットがコネクタ・バンドルに対してローカルでもリモートでも、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。これは、アプリケーション内でコネクタ・バンドルが直接実行できない場合に必要で、ICFにより、アプリケーションが外部的にデプロイされたバンドルと通信できるようになります。また、コネクタ・アーティファクトは、ローカル・システムとリモート・システムで同じにできます。
図9-5は、ICFフレームワークを示しており、Oracle Identity ManagerおよびOracle Waveset (OW)コネクタを単一のコネクタに集中することができます。
org.identityconnectors.framework.apiパッケージには、ICF APIが含まれています。Oracle Identity Managerでは、このAPIを使用して、コネクタ実装をコールします。このAPIは、サポートされている処理に関係なく、実装されているコネクタに関して一貫した外観を提供します。次の各項では、これらのインタフェースおよびクラスについて説明します。
ConnectorInfoManagerFactoryクラスは、Oracle Identity Managerが一連のバンドルからコネクタ・クラスをロードすることを可能にします。静的なgetInstanceメソッドは、ConnectorInfoManagerFactoryタイプのオブジェクトを返します。このオブジェクトを使用して、ConnectorInfoManagerへの参照を取得できます。(詳細は、第9.3.2項「ConnectorInfoManagerインタフェース」を参照してください。)例9-1に、ConnectorInfoManagerFactoryの実装を示します。
ConnectorInfoManagerインタフェースは、ConnectorInfoインスタンスのリストを管理します。各インスタンスがアイデンティティ・コネクタを表します。ConnectorInfoManagerFactoryに対してgetLocalManagerメソッドをコールすると、ConnectorInfoManagerが取得され、それにバンドルURLのリストが渡されます。ConnectorInfoManagerは、ConnectorInfoManagerFactoryに対してgetRemoteManagerメソッドをコールすることによっても取得できます。getRemoteManagerメソッドは、コネクタ・サーバーにデプロイされたコネクタに関する情報を取得するために使用されるRemoteFrameworkConnectionInfoandのインスタンスを受け入れます。
例9-2では、cInfoManagerFactoryがConnectorInfoManagerFactoryのインスタンスであり、bundleURLがバンドルURL (JARバンドルまたはそれを解凍した内容で構成されるディレクトリをポイントするURL)のリストです。
ConnectorKeyは、インストール環境内でConnectorインスタンスを一意に識別します。ConnectorKeyクラスには、例9-3に示すように、bundleName(コネクタ・バンドルの名前)、bundleVersion(コネクタ・バンドルのバージョン)およびconnectorName(コネクタ・バンドルの名前)を指定します。
ConnectorInfoインタフェースは、特定のアイデンティティ・コネクタに関する情報を格納します。格納されるのは、特定のアイデンティティ・コネクタに関する表示名、キーおよびメッセージの詳細です。例9-4に、ConnectorInfoを実装する方法を示します。
例9-4 ConnectorInfoの実装
//get the ConnectorInfo
ConnectorInfo info =
cInfoManager.findConnectorInfo(flatFileConnectorKey);
例では、cInfoManagerがConnectorInfoManagerであり、flatFileConnectorKeyがアイデンティティ・コネクタ・キーです。
APIConfigurationインタフェースは、SPI側とAPI側の両方の構成プロパティを示します。getConfigurationPropertiesメソッドは、コネクタの構成実装に基づいてConfigurationPropertiesインスタンスを返し、このインスタンスはデフォルトに初期化されます。その後、コール元は必要に応じてプロパティを変更できます。例9-5に、これを示します。
ConfigurationPropertiesインタフェースは、SPI構成をカプセル化し、リフレクションを使用して、アプリケーションで操作できる個々のプロパティを識別します。例9-6の定義に従って、setPropertyValueメソッドを使用してアイデンティティ・コネクタのすべての構成プロパティを設定します。
例9-6 setPropertyValueメソッド・シグネチャ
public void setPropertyValue (java.lang.String name, java.lang.Object value)
例9-7に、ConfigurationPropertiesインタフェースの実装を示します。
ConnectorFacadeFactoryクラスは、アプリケーションがコネクタ・インスタンスを取得したり、コネクタ・インスタンスのプールを管理することを可能にします。例9-8に、ConnectorFacadeFactoryの定義を示します。
ConnectorFacadeインタフェースは、ターゲット・システムでAPI側の特定のアイデンティティ・コネクタを表すことによってアイデンティティ・コネクタ処理を呼び出すために使用されます。例9-9に、ConnectorFacadeの実装を示します。
開発者は、ICF SPIを実装してアイデンティティ・コネクタを作成します。ICF SPIは多数のインタフェースで構成されますが、開発者が実装する必要があるのは、ターゲット・システムでサポートされているインタフェースのみです。SPIは、さらに必須インタフェース、処理インタフェースおよび機能ベースのインタフェースに分類できます。必須インタフェースは、サポートされている処理に関係なく実装する必要があり、コネクタの作成やターゲット・システムとの接続の維持に利用されるのに対し、処理インタフェースはコネクタで各種処理をサポートするために利用されます。機能ベースのインタフェースは、ICFでサポートされている特定の機能に対応しています。
詳細は、次の各項を参照してください。
2つのインタフェースの実装には、すべてのアイデンティティ・コネクタが必要になります。これらの2つのインタフェースは、ターゲット・システムとのアイデンティティ・コネクタを宣言し、初期化します。詳細は、次の各項を参照してください。
これはアイデンティティ・コネクタを宣言するためのメイン・インタフェースです。コネクタの多くは、接続が必要になったときにターゲット・システムとの接続を確立し、処理が終了したら接続を解除し、使用していたリソースをすべて解放します。インタフェースには、この目的のためにinitとdisposeのライフサイクル・メソッドが用意されています。
|
注意: コネクタ実装には、configurationClassおよびdisplayNameKeyの情報を提供することによって、org.identityconnectors.framework.spi.ConnectorClassタイプでアノテーションを付ける必要があります。displayNameKeyは、Messages.propertiesファイルに定義されたキーにする必要があります。 |
すべてのコネクタ実装に@ConnectorClassというアノテーションを付ける必要があります。ICFではコネクタ・バンドル内の最上位にあるすべての.classファイルをスキャンし、@ConnectorClassというアノテーションが付いたクラスを探すため、このアノテーションは必須です(これにより、バンドルに定義されたコネクタは自動的に検出されます)。このアノテーションには、次の要素が必要です。
configurationClass: このコネクタ用の構成クラス。このクラスにはターゲットに関するすべての情報が保持され、コネクタはこの情報を使用してターゲットに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行できます。構成クラスを実装する方法の詳細は、「org.identityconnectors.framework.spi.Configuration」を参照してください。
displayNameKey: メッセージ・カタログに存在する必要がある表示名キー。
例9-10に、コネクタ実装のサンプルを示します。
例9-10 フラット・ファイル・コネクタの実装
/**
* Flat file connector implementation. This connector supports create,
* delete, search and update operations.
*/
@ConnectorClass
(configurationClass=FlatFileConfigurationImpl.class,
displayNameKey="FLAT_FILE_CONNECTOR")
public class FlatFileConnector implements Connector,
CreateOp, DeleteOp,SearchOp<Map<String, String>>,UpdateOp{
次に、例9-10について説明します。
CreateOp: コネクタがターゲット・システムにエンティティを作成できるようにします。
DeleteOp: コネクタがターゲット・システムのエンティティを削除できるようにします。
SearchOp: コネクタがターゲット・システムのエンティティを検索できるようにします。
UpdateOp: コネクタがターゲット・システムの既存のエンティティを更新できるようにします。
詳細は、「処理インタフェースの実装」を参照してください。
次の各項では、コネクタ・メソッドを実装する方法を例示する情報とコード例を示します。コネクタ実装に関する完全なコードは、「フラット・ファイル・コネクタの開発」を参照してください。
initメソッドは、コネクタを初期化します。コネクタは、@ConnectorClassというアノテーションが付いた構成インスタンスを使用して自分自身を初期化します。initメソッドには、引数として構成オブジェクトを指定します。構成オブジェクトには、コネクタがターゲット・システムに接続するために必要なすべての情報が保持されています。
例9-11に、JDK 1.6でインタフェースのinitメソッドを実装する方法を示します。
|
注意: このドキュメントで紹介されているすべてのコード例において、JDK 1.6でインタフェースを実装するメソッドが使用されています。 |
例9-11 initメソッドの実装
@Override
public void init(Configuration config) {
this.flatFileConfig = (FlatFileConfiguration) config;
FlatFileIOFactory flatFileIOFactory =
FlatFileIOFactory.getInstance(flatFileConfig);
this.flatFileMetadata = flatFileIOFactory.getMetadataInstance();
this.flatFileParser = flatFileIOFactory.getFileParserInstance();
this.flatFileWriter = flatFileIOFactory.getFileWriterInstance();
log.ok("Initialization done");
}
|
注意: FlatFileIOFactory、FlatFileMetadata、FlatFileParserおよびFlatFileWriterはサポート・クラスであり、ICFには含まれていません。これらのクラスの実装は、「フラット・ファイル・コネクタの開発」に例示されています。 |
例9-11に示すinitメソッドの実装では、次のことを行います。
ターゲット・システムの構成情報を格納します。これは後で処理を実行するときに使用できます。
プロビジョニングおよびリコンシリエーションの処理を実行するときに使用されるすべてのサポート・クラスを初期化します。
disposeメソッドは、このコネクタ・インスタンスによって使用されていたリソースをすべて解放します。メソッドがコールされると、コネクタ・インスタンスが破棄され、使用できなくなります。例9-12に、disposeメソッドを実装する方法を示します。
getConfigurationメソッドは、initメソッドの使用時にコネクタに渡された構成インスタンスを返します。例9-13に、getConfigurationメソッドを実装する方法を示します。
例9-13 getConfigurationメソッドの実装
/**
* returns the Configuration of this connector
*/
@Override
public Configuration getConfiguration() {
return this.flatFileConfig;
}
|
注意: コンポーネントは、初期化後に構成インスタンスにアクセスできる必要がある場合があります。これはアクセッサ・メソッドgetConfiguration()によってサポートされています。 |
このインタフェースの実装は、コネクタの構成をカプセル化します。構成実装にはターゲット・システムに関して必要なすべての情報が保持され、コネクタ実装はこの情報を使用してターゲット・システムに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行します。実装には、setterとgetterがプロパティに定義されたデフォルトのコンストラクタが必要です。宣言されたすべてのプロパティが必要になるわけではありませんが、必須のプロパティについては、アノテーションorg.identityconnectors.framework.spi.ConfigurationPropertyによって必須としてマークする必要があります。構成実装はJava beanであり、すべてのインスタンス変数(必須かどうかは問わない)がデフォルト値を持ちます。たとえば、文字列userNameはターゲット・システムに接続するために使用され、必須の属性です。このデフォルト値はNULLです。userNameが必須の属性である場合、ICFはOracle Identity Managerから値が提供されるものと想定します。言い換えると、Oracle Identity Managerはこのパラメータを見落としてはなりません。見落とされた場合、コネクタからConfigurationExceptionがスローされます。
実装自体がコネクタに渡される前に、その実装によってすべての必須プロパティが存在し、検証されたことがチェックされる必要があります。インタフェースには、この目的のためにvalidateメソッドが用意されています。たとえば、ターゲットのIPアドレス、ターゲットに接続するときのユーザー名、そのユーザーのパスワードなど、必須の構成パラメータが3つ存在するものとします。validateメソッドでは、regexを使用して、NULL以外の値および有効なIPアドレスをチェックできます。
|
注意: ICFには、構成オブジェクトを拡張できる便利なベース・クラスorg.identityconnectors.framework.spi.AbstractConfigurationも用意されています。 |
例9-14 構成実装
/**
* Configuration implementation for the flat file connector.
*/
public class FlatFileConfigurationImpl extends AbstractConfiguration{
次の各項では、構成メソッドを実装する方法を例示する情報とコード例を示します。
構成実装では、次のメソッドの実装を提供する必要があります。
validateメソッドは、すべての必須プロパティの値が設定されていることをチェックします。また、構成プロパティの値がすべて有効であることを検証します。言い換えると、構成プロパティのすべての値が期待される範囲内にあり、期待される形式になっていることを検証します。構成が有効でない場合、実装によって最も固有のRuntimeExceptionが生成されます。固有の例外が利用不可の場合、実装ではConfigurationExceptionをスローできます。例9-15に、validateメソッドを実装する方法を示します。
例9-15 validateメソッドの実装
@Override
public void validate() {
// Validate if file exists and is usable
boolean validFile = (this.storeFile.exists() &&
this.storeFile.canRead() &&
this.storeFile.canWrite() &&
this.storeFile.isFile());
if (!validFile)
throw new ConfigurationException("User store file not valid");
FlatFileIOFactory.getInstance(this);
}
ここでは、指定されたターゲット・フラット・ファイルが有効かどうか(ファイルであるか、書込み可能か、読取り可能かなど)がチェックされます。有効でない場合は、例外が生成されます。
validateメソッドの実装では、プロパティの検証時にターゲット・システムに接続しないでください。
|
注意: この実装は、インスタンス変数(private File storeFile)およびサポート・クラス(FlatFileIOFactory)に依存します。完全な実装は、「フラット・ファイル・コネクタの開発」に例示されています。 |
setConnectorMessagesメソッドは、org.identityconnectors.framework.common.objects.ConnectorMessagesメッセージ・カタログ・インスタンスを設定し、コネクタがメッセージをローカライズすることを可能にします。例9-16に、setConnectorMessagesメソッドの定義を示します。
getConnectorMessagesメソッドは、setConnectorMessagesメソッドによって設定されたConnectorMessagesを返します。例9-17に、getConnectorMessagesメソッドの定義を示します。
次の各項では、アイデンティティ・コネクタ・プーリングや属性の正規化を有効にするときに使用されるインタフェースについて説明します。
ICFによる接続プーリングは、フレームワークでコネクタ・インスタンスのプールを管理し、プロビジョニングおよびリコンシリエーションの処理の実行時にそれらのコネクタ・インスタンスを使用できるようにする機能です。単純なConnectorインタフェースのかわりにPoolableConnectorインタフェースを実装することによって、コネクタでプーリングを使用できるようになります。この機能を使用するには、PoolableConnectorインタフェースを実装します。Connectorインタフェースを実装した場合、ICFは処理ごとに新しいコネクタ・インスタンスを作成し、ターゲットとの新しい接続を確立し、プロビジョニング/リコンシリエーションの処理を実行し、ターゲット・システムとの接続を解除し、最後にこのコネクタ・インスタンスを破棄します。したがって、PoolableConnectorを実装すると、構成可能なコネクタ・インスタンスのプールが管理され、多くの処理に再利用されるという利点があります。
構成可能なオプションの一部を次に示します。
プール内のアイドル状態およびアクティブ状態のコネクタ・オブジェクトの最大数(_maxObjects)
アイドル状態のコネクタ・オブジェクトの最大数(_maxIdle)
未使用のオブジェクトが利用可能になるのをプールで待つ最大時間(この時間が経過すると、オブジェクトを放棄)(_maxWait)
アイドル状態のオブジェクトを追い出すまでの最小待機時間(_minEvictableIdleTimeMillis)
アイドル状態のオブジェクトの最小数(_minIdle)
これらの値はコネクタAPI開発者が設定する必要があり、設定しなかった場合は、次のデフォルト値が使用されます。
_maxObjects = 10
_maxIdle = 10
_maxWait = 150 * 1000 ms
_minEvictableIdleTimeMillis = 120 * 1000 ms
_minIdle = 1
PoolableConnectorインタフェースはConnectorインタフェースを拡張します。これを実装すると、ICFが提供するアイデンティティ・コネクタ・プーリングが有効になります。ICFでは、コネクタ・インスタンスが使用される前に、そのインスタンスが動作していることを確認する必要があります。インタフェースには、この目的のためにcheckAliveメソッドが用意されています。例9-18に、フラット・ファイルPoolableConnectorの実装のサンプルを示します。
例9-18 フラット・ファイルPoolableConnectorの実装
/**
* Flat file connector implementation. This is a poolable connector
which supports create, delete, search and update operations.
*/
@ConnectorClass
(configurationClass=FlatFileConfigurationImpl.class,
displayNameKey="FLAT_FILE_CONNECTOR")
public class FlatFileConnector implements PoolableConnector,
CreateOp, DeleteOp,SearchOp<Map<String, String>>,UpdateOp{
PoolableConnectorインタフェースを実装するには、第9.4.1.1項「org.identityconnectors.framework.spi.Connector」で説明したすべてのメソッドに加えて、checkAliveメソッドの実装を提供します。checkAliveメソッドは、コネクタ・インスタンスが動作しているかどうかを確認するためのもので、ターゲット・システムでの処理用に使用できます。checkAliveは頻繁にコールできるため、開発者は実装を高速化する必要があります。メソッドは、コネクタが動作しなくなったときに、固有のRuntimeException(利用可能な場合)をスローする必要があります。例9-19に、checkAliveメソッドを実装する方法を示します。
このインタフェースは、コネクタに渡される属性を正規化する必要がある場合に、実装する必要があります。正規化では、表示、消費または比較用に値が標準形式に変換されます。たとえば、正規化では、テキスト値を大文字または小文字に変換したり、空白の切捨てを行ったり、DNの要素を特定の方法で並べることができます。
インタフェースには、この目的のためにnormalizeAttributeメソッドが定義されています。このメソッドには、引数としてObjectClassと正規化対象の属性を指定し、戻り値は正規化した属性になります。属性の正規化は、次のような様々な項目を処理するときに適用されます。
SearchOpに渡されるフィルタ
SearchOpから返される結果
SyncOpから返される結果
UpdateAttributeValuesOpに渡される属性
UpdateAttributeValuesOpから返されるUid
UpdateOpに渡される属性
UpdateOpから返されるUid
CreateOpに渡される属性
CreateOpから返されるUid
DeleteOpに渡されるUid
例9-20に、normalizeAttributeメソッドの定義を示します。
処理インタフェースごとに、コネクタがターゲット・システムで実行できるアクション(サポートされている場合)が定義されています。処理インタフェースは、org.identityconnectors.framework.spi.operationsパッケージに属しています。これらの処理インタフェースの名前は次のとおりですが、各インタフェースの詳細は後続の項を参照してください。
AuthenticateOp
CreateOp
DeleteOp
ResolveUsernameOp
SchemaOp
ScriptOnConnectorOp
ScriptOnResourceOp
SearchOp<T>SyncOp
TestOp
UpdateAttributeValuesOp
UpdateOp
次の各項では、これらの処理のいくつかについて詳しく説明します。
SchemaOpインタフェースを実装すると、ターゲット・システムで処理できるオブジェクトをコネクタが表すことが可能になります。コネクタから返されるスキーマは、コネクタが管理用に公開するオブジェクト・クラスを表します。各オブジェクト・クラスは、名前、説明および一連の属性定義を持ちます。各属性定義には、名前、構文の他、複数値、単一値、読取り可能、書込み可能などのプロパティを表す特定のフラグが含まれます。
コネクタから返されるスキーマは、コネクタが公開する各タイプのオブジェクトの属性を表します。内部表現からこのスキーマ形式への変換が必要になる場合もあります。それ以外に、スキーマは、ターゲットAPIへのコールを通じてのみネイティブに利用できる情報を属性として表す場合もあります。SPI実装でネイティブ表現とそれに対応するConnectorObjectの間のマッピングがどのように行われるかに関係なく、スキーマはメタデータを提供し、このメタデータを通じて、各タイプ(objectClass)のConnectorObject内に含まれるものとクライアントが想定する情報を表します。
このインタフェースを実装するには、例9-21の定義に従って、schemaメソッドの実装を提供します。
実装では、このアイデンティティ・コネクタでサポートされるオブジェクトのタイプを含むスキーマを返す必要があります。
例9-22 schemaメソッドの実装
@Override
public Schema schema() {
SchemaBuilder flatFileSchemaBldr = new SchemaBuilder(this.getClass());
Set<AttributeInfo> attrInfos = new HashSet<AttributeInfo>();
for (String fieldName : flatFileMetadata.getOrderedTextFieldNames()) {
AttributeInfoBuilder attrBuilder = new AttributeInfoBuilder();
attrBuilder.setName(fieldName);
attrBuilder.setCreateable(true);
attrBuilder.setUpdateable(true);
attrInfos.add(attrBuilder.build());
}
// Supported class and attributes
flatFileSchemaBldr.defineObjectClass
(ObjectClass.ACCOUNT.getDisplayNameKey(), attrInfos);
return flatFileSchemaBldr.build();
}
|
注意: 返されるスキーマにUidが含まれないようにする必要があります。 |
CreateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの作成が可能になります。このインタフェースを実装するには、例9-23に示すように、create()メソッドの実装を提供します。
例9-23 createメソッド・シグネチャ
public Uid create (ObjectClass objectClass, Set<Attribute> attributes, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、一連のオブジェクト属性および処理オプションを指定します。実装では、渡されたオブジェクト属性とObjectClassで定義されたオブジェクト・タイプを使用して、ターゲット・システムにオブジェクトを作成します。ObjectClass引数では、作成対象のオブジェクトのクラスを指定します。作成対象のオブジェクトのクラスは、作成処理に対する入力の1つです。例9-24に示すように、ObjectClassはcreate()メソッドの最初の引数です。
例9-24 createメソッドの実装
@Override
public Uid create(ObjectClass arg0, Set<Attribute> attrs,
OperationOptions ops) {
System.out.println("Creating user account " + attrs);
assertUserObjectClass(arg0);
try {
FlatFileUserAccount accountRecord = new FlatFileUserAccount(attrs);
// Assert uid is there
assertUidPresence(accountRecord);
// Create the user
this.flatFileWriter.addAccount(accountRecord);
// Return uid
String uniqueAttrField = this.flatFileConfig
.getUniqueAttributeName();
String uniqueAttrVal = accountRecord
.getAttributeValue(uniqueAttrField);
System.out.println("User " + uniqueAttrVal + " created");
return new Uid(uniqueAttrVal);
} catch (Exception ex) {
// If account exists
if (ex.getMessage().contains("exists"))
throw new AlreadyExistsException(ex);
// For all other causes
System.out.println("Error in create " + ex.getMessage());
throw ConnectorException.wrap(ex);
}
}
処理が成功すると、ターゲット・システム上でのオブジェクト識別子を表すUidインスタンスが作成され、返されます。コール元は、このUidを使用して、作成されたオブジェクトを参照できます。
DeleteOpインタフェースを実装すると、ターゲット・システムからのオブジェクトの削除が可能になります。このインタフェースを実装するには、例9-25の定義に従って、deleteメソッドの実装を提供します。
例9-25 deleteメソッド・シグネチャ
public void delete (ObjectClass objectClass, Uid uid, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、ターゲット・システムから削除するオブジェクトのUidおよび処理オプションを指定します。実装では、指定されたUidで識別されるオブジェクトをターゲット・システムから削除します。オブジェクトがターゲット・システムに存在しない場合は、org.identityconnectors.framework.common.exceptions.UnknownUidExceptionが生成されます。例9-26に、deleteメソッドを実装する方法を示します。
例9-26 deleteメソッドの実装
@Override
public void delete(ObjectClass arg0, Uid arg1, OperationOptions arg2) {
final String uidVal = arg1.getUidValue();
this.flatFileWriter.deleteAccount(uidVal);
log.ok("Account {0} deleted", uidVal);
}
|
注意: 削除処理が失敗すると、ICFはRuntimeExceptionのサブクラスを生成します。詳細は、Oracle Fusion Middleware Java APIリファレンス(Identity Connector Framework用)を参照してください。 |
SearchOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの検索が可能になります。この場合、検索処理では次のことが行われます。
一般に指定される検索条件を実装するためのネイティブ・フィルタが作成されます。
実際の問合せが実行されます。
SPIでこれらのメソッドを実装すると、APIで検索をサポートできるようになります。APIでは、指定されたフィルタ条件をネイティブ検索条件に変換することなどによって、コネクタで実行されないすべてのフィルタを(結果の後処理を通じて)実行します。
このインタフェースを実装するには、次の各項にまとめられたcreateFilterTranslatorメソッドおよびexecuteQueryメソッドの実装を提供します。
createFilterTranslatorメソッドは、API側から渡されたICFフィルタ・オブジェクトをネイティブ問合せに変換するFilterTranslator実装のインスタンスを返します。変換後、ICFは問合せをexecuteQueryメソッドに渡します。例9-27に、createFilterTranslatorメソッドの定義を示します。
例9-27 createFilterTranslatorメソッド・シグネチャ
public FilterTranslator createFilterTranslator (ObjectClass oClass, OperationsOptions options)
|
注意: NULLの戻り値は許可されていません。 |
例9-28に、createFilterTranslatorメソッドの実装を示します。
例9-28 createFilterTranslatorメソッドの実装
@Override
public FilterTranslator<Map<String, String>> createFilterTranslator
(ObjectClass arg0, OperationOptions arg1) {
return new ContainsAllValuesImpl() {
};
}
この例では、単一タイプの検索述語(ContainsAllValues)のみがサポートされています。ContainsAllValuesImplの実装例は、「AbstractFilterTranslator<T>の実装」を参照してください。ContainsAllValuesの実装では、条件の形式をネイティブ形式に変換します。属性Aには、すべての値V(1)、V(2) ... V(N)が含まれます。
org.identityconnectors.framework.common.objects.filter.FilterTranslatorの詳細は、「共通クラス」を参照してください。
executeQueryメソッドは、FilterTranslatorの実装(「createFilterTranslatorメソッドの実装」を参照)によって生成されるすべての問合せに対してコールされます。例9-29に示すように、ObjectClass(アカウントやグループなど)、問合せ、見つかったオブジェクトを処理するときにコールバックとして使用されるResultsHandlerのインスタンスおよび処理オプションを指定します。
例9-29 executeQueryメソッド・シグネチャ
public void executeQuery
(ObjectClass oClass, T query,
ResultsHandler handler, OperationOptions options)
executeQueryメソッドの実装では、渡された問合せを使用してターゲット・オブジェクトを検索し、見つかったターゲット・オブジェクトごとにConnectorObjectのインスタンスを作成し、ResultsHandlerを使用してConnectorObjectを処理します。ConnectorObjectは、ターゲット・リソース・オブジェクトのICF表現です。ObjectClass、Uid、名前、一連の属性などの情報が保持されます。ConnectorObjectは検索の中心となります。executeQueryは、ConnectorObjectをストリームとしてResultsHandlerに送り、そしてクライアントに送ります。例9-30に、exectueQueryメソッドを実装する方法を示します。
例9-30 executeQueryメソッドの実装
@Override
public void executeQuery(ObjectClass objectClass,
Map<String, String> matchSet, ResultsHandler resultHandler,
OperationOptions ops) {
// searches the flat file for accounts which fulfil the condition 'matchSet' created by FilterTranslator
Iterator<FlatFileUserAccount> userAccountIterator = this.flatFileParser
.getAccountIterator(matchSet);
boolean handleMore = true;
while (userAccountIterator.hasNext() && handleMore) {
FlatFileUserAccount userAcc = userAccountIterator.next();
ConnectorObject userAccObject = convertToConnectorObject(userAcc);
// Let the client handle the result by doing callback
handleMore = resultHandler.handle(userAccObject);
}
while (userAccountIterator.hasNext()) {
FlatFileUserAccount userAcc = userAccountIterator.next();
ConnectorObject userAccObject = convertToConnectorObject(userAcc);
if (!resultHandler.handle(userAccObject)) {
System.out.println("Not able to handle " + userAcc);
break;
}
}
}
UpdateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの更新が可能になります。このインタフェースを実装するには、例9-31の定義に従って、updateメソッドの実装を提供します。
例9-31 updateメソッド・シグネチャ
public Uid update(ObjectClass oClass, Uid uid, Set<Attribute> attributes, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、更新対象のオブジェクトのUid、更新対象の一連のオブジェクト属性および処理オプションを指定します。実装では、ターゲット・システム上でUidによって識別されるオブジェクトを新しい属性値で更新します。Uidによって識別されるオブジェクトがターゲット・システムに存在しない場合は、UnknowUidExceptionが生成されます。例9-32に、updateメソッドを実装する方法を示します。
例9-32 updateメソッドの実装
@Override
public Uid update(ObjectClass arg0, Uid arg1,
Set<Attribute> arg2, OperationOptions arg3) {
String accountIdentifier = arg1.getUidValue();
// Fetch the account
FlatFileUserAccount accountToBeUpdated = this.flatFileParser
.getAccount(accountIdentifier);
// Update
accountToBeUpdated.updateAttributes(arg2);
this.flatFileWriter
.modifyAccount(accountIdentifier, accountToBeUpdated);
log.ok("Account {0} updated", accountIdentifier);
// Return new uid
String newAccountIdentifier = accountToBeUpdated
.getAttributeValue
(this.flatFileConfig.getUniqueAttributeName());
return new Uid(newAccountIdentifier);
}
前の各項で示したように、ICFには多数のクラスが用意されています。最も重要なクラスは次のとおりです。
org.identityconnectors.framework.common.objects.Attribute
属性は、ターゲット・システム・オブジェクト内の値の名前付きコレクションです。ターゲット・システム・オブジェクトには多数の属性が保持され、それぞれの属性が多数の値を持つ場合があります。最も単純な形式の属性は、ターゲット・システム・オブジェクトの名前/値ペアとみなすことができます。空の値およびNULL値がサポートされています。開発者は、org.identityconnectors.framework.common.objects.AttributeBuilderを使用して、属性インスタンスを構築する必要があります。
|
注意: このモデルでは、すべての属性が構文的に複数値になります。単一値になる特定の属性は、セマンティック制限のみです。 |
org.identityconnectors.framework.common.objects.Uid
ターゲット・リソース上でのオブジェクトの一意の識別子を表す単一値属性です(Uidは属性のサブクラスです)。理想的には、不変である必要があります。
|
注意: 単一値属性は、特に一意の識別子となるUIDに関連します。 |
org.identityconnectors.framework.common.objects.ObjectClass
ObjectClassは、ターゲット・システム上のオブジェクトのタイプを定義します。このようなタイプの例としては、アカウント、グループまたは組織があります。ICFでは、アカウントのObjectClassとしてObjectClass.ACCOUNT、グループのObjectClassとしてObjectClass.GROUPが事前に定義されています。
org.identityconnectors.framework.common.objects.ConnectorObject
ConnectorObjectは、ターゲット・システム上のオブジェクト(アカウントやグループなど)を表します。開発者は、org.identityconnectors.framework.common.objects.ConnectorObjectBuilderを使用して、ConnectorObjectを構築する必要があります。
org.identityconnectors.common.security.GuardedString
ガード文字列は、パスワードをメモリーにプレーン文字列形式で格納するという問題を解決するセキュアな文字列実装です。パスワードは、暗号化された形式でバイトとして格納されます。暗号化鍵はランダムに生成されます。
org.identityconnectors.framework.common.objects.filter.FilterTranslator
FilterTranslaterオブジェクトは、検索処理の実行時に、ICFのAPI側で指定されたすべてのフィルタをネイティブ問合せに変換します。ICFフィルタでは、検索述語と論理演算子の両方がサポートされています。
検索述語では、指定した属性の値に基づいてオブジェクトを照合します。たとえば、EqualsFilterは、少なくとも1つの属性値が指定した値と等しい場合に、trueを返します。
論理演算子ANDおよびORでは、検索述語を結合して、複雑な式を作成します。たとえば、「A AND B」という形式の式は、AとBの両方がtrueの場合にのみtrueになります。「A OR B」という形式の式は、AとBの少なくとも一方がtrueの場合にtrueになります。
ICFが提供するAbstractFilterTranslator<T>ベース・クラスを使用すると、検索の実装が容易になります。FilterTranslatorサブクラスは、次のものを可能なかぎりオーバーライドする必要があります。
createAndExpression(T, T)
createOrExpression(T, T)
createContainsExpression(ContainsFilter, boolean)
createEndsWithExpression(EndsWithFilter, boolean)
createEqualsExpression(EqualsFilter, boolean)
createGreaterThanExpression(GreaterThanFilter, boolean)
createGreaterThanOrEqualExpression(GreaterThanOrEqualFilter, boolean)
createStartsWithExpression(StartsWithFilter, boolean)
createContainsAllValuesExpression(ContainsAllValuesFilter, boolean)
詳細は、第9.4.3.4項「SearchOpインタフェースの実装」を参照してください。
org.identityconnectors.framework.common.objects.ResultsHandler
これは、処理で1つ以上の結果が返される場合のコールバック・インタフェースです。サブクラスはメソッドを処理するための実装を提供する必要があるのに対し、コール元は結果に対する処理を決めることができます。現在、これはSearchOpインタフェースでのみ使用されます。詳細は、第9.4.3.4項「SearchOpインタフェースの実装」を参照してください。
アイデンティティ・コネクタ・バンドルは、特定のターゲット・システムに固有の実装です。バンドルは、アイデンティティ・コネクタがターゲット・システムに接続し、処理を実行するために必要なすべてのファイルを含むJavaアーカイブ(JAR)として提供されます。ICFで認識される特別な属性(MANIFESTファイルで定義)も含まれます。それらは次のとおりです。
ConnectorBundle-FrameworkVersionは、このアイデンティティ・コネクタ・バンドルを動作させるために最低限必要なICFのバージョンです。新しいICFバージョンには下位互換性があります。
ConnectorBundle-Nameは、このアイデンティティ・コネクタ・バンドルの一意の名前です。一般に、パッケージ名になります。
ConnectorBundle-Versionは、このバンドルのバージョンです。Oracle Identity Managerの特定のデプロイメント内で、ConnectorBundle-NameとConnectorBundle-Versionの組合せが一意になるようにする必要があります。
共通クラスを再利用する場合などに、アイデンティティ・コネクタ・バンドルを拡張します。AbtractDatabaseConnectorがよい例です。異なるタイプのコネクタで、JDBCを使用してデータベース表にアクセスする同一の基本ロジックを再利用できるためです。データベース表用のコネクタは、この共通コードをOracle Databaseユーザー用のコネクタ、IBM DB2データベース・ユーザー用のコネクタおよびMySQLユーザー用のコネクタと共有できます。
特定のコネクタを拡張するには、拡張したバンドルを新しいバンドルの/libディレクトリに追加し、ターゲット・クラスをサブクラス化する新しいクラスを作成します。この方法は、AbstractDatabaseConnectorバンドルを使用して例示できます。共通ロジックは、次のように共通バンドルに含まれます。
|
注意: 元のバンドルは拡張しません。かわりに、元のバンドルをラップする新しいバンドルの中に元のバンドルを組み込むことで、コネクタを拡張します。 |
META-INF/MANIFEST.MF
ConnectorBundle-FrameworkVersion: 1.0
ConnectorBundle-Name: org.identityconnectors.database.common
ConnectorBundle-Version: 1.0
org.identityconnectors/database/common/AbstractDatabaseConnector.class
|
注意: このアイデンティティ・コネクタには、@ConnectorClassというアノテーションは付きません。 |
org/identityconnectors/database/common/*(その他の共通ソース・ファイル)
lib/
データベース(リソース)に固有のバンドルを必要な数だけ使用できます。例:
META-INF/MANIFEST.MF
ConnectorBundle-FrameworkVersion: 1.0
ConnectorBundle-Name: org.identityconnectors.database.mysql
ConnectorBundle-Version: 1.0
org/identityconnectors/database/mysql/MySQLConnector.class (AbstractDatabaseConnectorのサブクラス)
|
注意: このアイデンティティ・コネクタには、@ConnectorClassというアノテーションが付きます。 |
org/identityconnectors/database/mysql/*(その他のMySQLソース・ファイル)
lib/org.identityconnectors.database.common-1.0.jar(前述の親バンドル)
lib/*(特定のデータベース・ドライバおよびライブラリ(必要に応じて))
アイデンティティ・コネクタ・バンドルがアプリケーション内で直接実行されない場合は、アイデンティティ・コネクタ・サーバーが必要です。ICFアーキテクチャでは、1つ以上のアイデンティティ・コネクタ・サーバーを使用することで、アプリケーションと外部にデプロイされたアイデンティティ・コネクタ・バンドルとの通信が可能になります。アイデンティティ・コネクタ・サーバーは、Java (tm)およびMicrosoft .NET Frameworkアプリケーションに対応しています。
単一のコネクタ・サーバーで複数のICFコネクタをサポートでき、これらのICFコネクタのタイプもそれぞれ異なっていてかまいません。単一のICFコネクタを使用して、複数のターゲットと通信できます。
図9-6に、Oracle Identity ManagerコネクタがICFコネクタを介してリソースと統合される仕組みを示します。
次に、図9-6について説明します。
Oracle Identity Managerコネクタは、ターゲット・リソースと直接対話することはありません。かわりに、適切なICFコネクタを介して、作成、読取り、更新、削除および問合せ(CRUDQ)の各処理が実行されます。
単一のICFコネクタを使用して、リソース・タイプが同じ複数のリソースに接続できます。図9-6では、LDAP用のICFコネクタを使用して、ローカルLDAPリソースとリモートLDAPリソースの両方に接続しています。
.NETコネクタ・サーバーを使用して、.NET ICFコネクタをターゲット・ホストにデプロイします。この方法でActive Directoryリソースが接続されます。
Google Apps用のICFコネクタは、インターネット上のGoogle Appsとの接続に使用されます。
図には示されていませんが、コネクタ・サーバーではリソース・タイプが異なる複数のICFコネクタをサポートできます。
コネクタ・サーバーのタイプについては、次の各項で説明します。
|
ヒント: どちらのコネクタ・サーバーを構成する場合も、次の情報(インストール時に定義)を準備してください。
|
アプリケーションと同じJava仮想マシン(JVM)でJavaコネクタ・バンドルを実行しない場合は、Javaコネクタ・サーバーを使用します。バンドルを管理対象ターゲット・システムと同じホストにデプロイすると、動作速度が向上するため、このデプロイメントはパフォーマンスの面で有効です。また、Javaコネクタ・サーバーを使用すると、JNIベースのコネクタの障害が原因でアプリケーションJVMがクラッシュする可能性を排除できます。
Javaコネクタ・サーバーの使用方法については、次の各項で説明します。
Javaコネクタ・サーバーをインストールおよび構成するには、次の手順を実行します。
Javaコネクタ・サーバーをインストールするコンピュータに新しいディレクトリを作成します。この項では、このディレクトリをCONNECTOR_SERVER_HOMEとしています。
手順1で作成した新しいディレクトリにJavaコネクタ・サーバー・パッケージを解凍します。Javaコネクタ・サーバーは、次のURLにあるOracle Technology Network Webサイトからダウンロードできます。
conf/ディレクトリにあるConnectorServer.propertiesファイルで、デプロイメントで必要になるプロパティを設定します。表9-1に、ConnectorServer.propertiesファイル内のプロパティを示します。
表9-1 ConnectorServer.propertiesファイル内のプロパティ
| プロパティ | 説明 |
|---|---|
|
connectorserver.port |
Javaコネクタ・サーバーがリクエストをリスニングするポート。デフォルト値は |
|
connectorserver.bundleDir |
コネクタ・バンドルがデプロイされるディレクトリ。デフォルト値は |
|
connectorserver.libDir |
依存ライブラリを配置するディレクトリ。デフォルト値は |
|
connectorserver.usessl |
trueに設定すると、Javaコネクタ・サーバーでSSLを使用してセキュアな通信が実現されます。デフォルト値は trueを指定する場合は、Javaコネクタ・サーバーの起動時にコマンドラインで次のオプションを使用してください。
|
|
connectorserver.ifaddress |
バインド・アドレス。このプロパティを設定する場合は、必要に応じてファイル内でプロパティのコメントアウトを解除してください。バインド・アドレスは、コンピュータにその他のNICが取り付けられている場合に役立ちます。 |
|
connectorserver.key |
Javaコネクタ・サーバー・キー。 |
ConnectorServer.propertiesファイル内のプロパティを次のように設定します。
connectorserver.keyを設定するには、/setKeyオプションを指定してJavaコネクタ・サーバーを実行します。詳細は、「Microsoft WindowsでのJavaコネクタ・サーバーの実行」および「SolarisおよびLinuxでのJavaコネクタ・サーバーの実行」を参照してください。
その他すべてのプロパティについては、ConnectorServer.propertiesファイルを手動で編集します。
confディレクトリにはlogging.propertiesファイルもあり、デプロイメントで必要になる場合は編集できます。
Microsoft WindowsでJavaコネクタ・サーバーを実行するには、次のようにConnectorServer.batスクリプトを使用します。
「Javaコネクタ・サーバーのインストールおよび構成」の説明に従って、デプロイメントで必要になるプロパティをConnectorServer.propertiesファイルで設定したことを確認します。
CONNECTOR_SERVER_HOME\binディレクトリに移動し、ConnectorServer.batスクリプトを探します。
表9-2に、ConnectorServer.batスクリプトでサポートされているオプションを示します。
表9-2 ConnectorServer.batスクリプトでサポートされているオプション
| オプション | 説明 |
|---|---|
|
/install [serviceName] ["-J java-option"] |
Javaコネクタ・サーバーをMicrosoft Windowsサービスとしてインストールします。 必要に応じて、サービス名およびJavaオプションを指定できます。サービス名を指定しない場合は、ConnectorServerJavaがデフォルトの名前として使用されます。 |
|
/run ["-J java-option"] |
コンソールからJavaコネクタ・サーバーを実行します。 必要に応じて、Javaオプションを指定できます。たとえば、Javaコネクタ・サーバーをSSL対応として実行するには、次のようにします。 ConnectorServer.bat /run "-J-Djavax.net.ssl.keyStore=mykeystore.jks" "-J-Djavax.net.ssl.keyStorePassword=password" |
|
/setKey [key] |
Javaコネクタ・サーバー・キーを設定します。ConnectorServer.batスクリプトでは、ConnectorServer.propertiesファイル内のconnectorserver.keyプロパティにキーのハッシュ値を格納します。 |
|
/uninstall [serviceName] |
Javaコネクタ・サーバーをアンインストールします。サービス名を指定しない場合は、スクリプトによってConnectorServerJavaサービスがアンインストールされます。 |
Javaコネクタ・サーバーを停止する必要がある場合は、対応するMicrosoft Windowsサービスを停止します。
SolarisおよびLinuxでJavaコネクタ・サーバーを実行するには、次のようにconnectorserver.shスクリプトを使用します。
「Javaコネクタ・サーバーのインストールおよび構成」の説明に従って、デプロイメントで必要になるプロパティをConnectorServer.propertiesファイルで設定したことを確認します。
CONNECTOR_SERVER_HOME/binディレクトリに移動します。
chmodコマンドを使用して、connectorserver.shスクリプトを実行可能にするための権限を設定します。
connectorserver.shスクリプトを実行します。
表9-3に、connectorserver.shスクリプトでサポートされているオプションを示します。
表9-3 connectorserver.shスクリプトでサポートされているオプション
| オプション | 説明 |
|---|---|
|
/run [ -Jjava-option ] |
コンソールからJavaコネクタ・サーバーを実行します。必要に応じて、1つ以上のJavaオプションを指定できます。たとえば、Javaコネクタ・サーバーをSSL対応として実行するには、次のようにします。 ./connectorserver.sh /run -J-Djavax.net.ssl.keyStore=mykeystore.jks -J-Djavax.net.ssl.keyStorePassword=password |
|
/start [ -Jjava-option ] |
Javaコネクタ・サーバーをバックグラウンドで実行します。必要に応じて、1つ以上のJavaオプションを指定できます。 |
|
/stop |
プロセスが終了するまで最大で5秒間待ってから、Javaコネクタ・サーバーを停止します。 |
|
/stop n |
プロセスが終了するまで最大でn秒間待ってから、Javaコネクタ・サーバーを停止します。 |
|
/stop -force |
Javaコネクタ・サーバーを停止します。最大で5秒間待った後もまだプロセスが実行されている場合は、 |
|
/stop n -force |
Javaコネクタ・サーバーを停止します。最大でn秒間待った後もまだプロセスが実行されている場合は、 |
|
/setKey key |
Javaコネクタ・サーバー・キーを設定します。connectorserver.shスクリプトでは、ConnectorServer.propertiesファイル内のconnectorserver.keyプロパティにキーのハッシュ値を格納します。 |
この項では、Javaコネクタ・サーバーにJavaコネクタ・バンドルをデプロイする手順について説明します。
Javaコネクタ・サーバー・ディレクトリのbundlesディレクトリに移動します。
Javaコネクタ・バンドルJARをbundlesディレクトリにコピーします。
アイデンティティ・コネクタで必要になるサード・パーティJARファイルが存在する場合は、それらをlibディレクトリに追加します。
Javaコネクタ・サーバーを再起動します。
Secure Sockets Layer (SSL)を使用してコネクタ・サーバーと通信するには、次の手順を実行します。
コネクタ・サーバーのシステムにSSL証明書をデプロイします。
SSLソケットを提供するようにコネクタ・サーバーを構成します。
SSLを使用してコネクタ・サーバーと通信するようにアプリケーションを構成します。
アイデンティティ・コネクタ・サーバーとの接続構成に固有の注意事項は、ターゲット・システムのマニュアルを参照してください。各SSL対応コネクタ・サーバーとの接続を確立するときにはSSL接続が必要になることをアプリケーションに指示します。さらに、コネクタ・サーバーで使用されるSSL証明書のいずれかが非標準認証局によって発行される場合は、追加の認証局を考慮するようにアプリケーションを構成する必要があります。認証局に関する注意事項は、該当するマニュアルを参照してください。
|
注意: Javaアプリケーションにおいて非標準認証局に関する問題を解決するには、アプリケーションの起動時に次のJavaシステム・プロパティが渡されるようにします。
また、非標準認証局を標準の${JAVA_HOME}/lib/security/cacertsディレクトリにインポートすることもできます。 |
アプリケーションがJavaで記述されていて、コネクタ・バンドルがC#で記述されている場合は、Microsoft .NET Framework(.NET)コネクタ・サーバーを使用すると便利です。Java Platform, Enterprise Edition (JEE (tm))アプリケーションではC#クラスをロードできないため、.NETコネクタ・サーバーの配下にC#バンドルをデプロイできます。これにより、Javaアプリケーションはネットワーク上でC#(.NET)コネクタ・サーバーと通信できるようになります。C#(.NET)コネクタ・サーバーは、C#バンドルへの認証アプリケーション・アクセスを実現するプロキシとして機能します。次の各項では、追加情報を示します。
.NETコネクタ・サーバーを実行するための最低要件は次のとおりです。
Microsoft Windows Server 2003または2008
Microsoft .NET Framework 3.5以上
追加要件の有無は、特定の.NETアイデンティティ・コネクタのドキュメントを参照してください。
.NETコネクタ・サーバーをインストールするには、ServiceInstall.msiファイルを実行し、インストール・ウィザードに表示される指示に従います。インストールが完了すると、コネクタ・サーバーはWindowsサービスとしてインストールされます。
.NETコネクタ・サーバーを構成するには、次の手順を実行します。共通構成には、ポート、トレース、SSL設定およびコネクタ・サーバー・キーが含まれます。
Microsoftサービス・コンソールを起動します。
コネクタ・サーバーが現在実行されているかどうかを確認します。実行されている場合は停止します。
コマンド・プロンプトを使用して、コネクタ・サーバーにキーを設定します。
このキーは、クライアントがこのコネクタ・サーバーに接続するときに必要になります。
コネクタ・サーバーがインストールされているディレクトリに移動します。
デフォルト: \Program Files\Identity Connectors\Connector Server
次のコマンドを実行します。
ConnectorServer /setkey NEWKEY
ここで、NEWKEYはキーの値です。
connectorserver.exe.config内の設定を調べて、その他のプロパティを構成します。
connectorserver.exe.configファイルには、コネクタ・サーバーに関する情報が含まれています。最もよく変更するのは、ポート、SSL構成およびトレース設定です。ポートおよびSSL設定は、次のようにAppSettingsというタグ内にあります。
<add key="connectorserver.port" value="8759" /> <add key="connectorserver.usessl" value="false" /> <add key="connectorserver.certificatestorename" value="ConnectorServerSSLCertificate" /> <add key="connectorserver.ifaddress" value="0.0.0.0" />
ポートを設定するには、connectorserver.portの値を変更します。SSLを使用するには、connectorserver.usesslの値をtrueに設定し、connectorserver.certifacatestorenameの値を証明書ストアの名前に設定します。リスニング・ソケットは特定のアドレスにバインドすることも、0.0.0.0のままにすることもできます。コネクタ・サーバーをSSL対応として構成する方法の詳細は、第9.6.1.5項「SSLを使用したコネクタ・サーバーとの通信」を参照してください。トレース設定の構成の詳細は、第9.6.2.3項「トレース設定の構成」を参照してください。
コネクタ・サーバーでは、標準の.NETトレース・メカニズムが使用されます。トレース設定は、connectorserver.exe.config構成ファイルに定義されています。例9-33に、定義の例を示します。
例9-33 トレース設定の定義
<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<remove name="Default" />
<add name="myListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\connectorserver2.log"
traceOutputOptions="DateTime">
<filter type="System.Diagnostics.EventTypeFilter"
initializeData="Information" />
</add>
</listeners>
</trace>
</system.diagnostics>
デフォルト設定でも十分適していますが、これらの設定を次のように変更してもかまいません。
トレース量を減らすには、フィルタ・タイプのinitializeData設定をWarningまたはErrorに変更します。
より詳細なロギングを行うには、値をVerboseまたはAllに設定します。
|
注意: ロギングの量は、コネクタ・サーバーのパフォーマンスに直接影響します。 |
構成を変更する場合は、コネクタ・サーバーの停止と再起動が必要になります。
|
注意: トレース・オプションの詳細は、System.Diagnosticsに関するMicrosoft .NETドキュメントを参照してください。 |
.NETコネクタ・サーバーを実行する最適な方法は、Windowsサービスとして実行することです。インストール時に、コネクタ・サーバーはWindowsサービスとしてインストールされます。これが環境に適さない場合は、コマンド・プロンプトで/installまたは/uninstall引数を使用して、コネクタ・サーバーをWindowsサービスとしてインストールまたはアンインストールできます。
コネクタ・サーバーを対話形式で実行するには、ConnectorServer /runコマンドを実行します。
新しいアイデンティティ・コネクタをインストールするには、コネクタ・サーバーがインストールされているディレクトリに移動し、このディレクトリに新しいアイデンティティ・コネクタのZIPを解凍してから、コネクタ・サーバーを再起動します。
