4 Identity Connector Frameworkの理解
Oracle Identity Managerでは、Identity Connector Framework (ICF)を使用してアイデンティティ・コネクタを開発および構築できます。ICFにより、Oracle Identity Managerが接続先の他のアプリケーションから切り離されます。そのため、アイデンティティ・コネクタを構築およびテストしてから、Oracle Identity Managerと統合できます。
この章は、概念情報およびコード例を示す次の項で構成されます。
ノート:
以前のリリースのOracle Identity Managerでは、他のオプションによってアイデンティティ・コネクタを構築していました。これらのオプションも引き続きサポートされていますが、ICFを使用して新しいアイデンティティ・コネクタを構築することをお薦めします。
4.1 ICFの利点
ICFの利点には、単一プラットフォームの使用、単純なインストール、ステートレスな設計、将来の再利用などがあります。
ICFには次の利点があります。
-
単一のプラットフォーム: アイデンティティ・コネクタは、Oracle Identity ManagerおよびOracle Waveset (OW)間で共有されており、Oracle Identity ManagerおよびOWの両方に単一のコネクタを使用して外部アイデンティティ対応のアプリケーションと通信できるように、同じプラットフォーム上に構築されています。
-
単純なインストール: ICFは、インストール中の手動の構成として、コネクタ・ファイルおよびコード・ファイルのコピーがICFによって自動的に処理されるなど、単純なインストールを提供します。
-
設計上ステートレス: アイデンティティ・コネクタは、設計上ステートレスです。アイデンティティ・コネクタには何も格納されません。コール側アプリケーションからコネクタに構成値(ターゲット・アプリケーションに接続するために必要な情報を含む)が提供されます。これは、アイデンティティ・コネクタがステートレスであるため、各バンドル実装はできるだけ単純な状態に保たれ、コール側アプリケーションの実装との結合も回避されます。
-
ICF共通: ICFでは、Oracle Identity ManagerのICFベースのコネクタに共通のコネクタ統合レイヤーを提供し、ICF共通を開発するための開発作業は必要ありません。
-
リモート実行: ICFでは、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行がサポートされています。
-
JVMの独立性: リモートICFにより、JVMの独立性が提供され、異なるホストでのJavaコネクタの実行によるJVM競合を防止します。
-
再利用: 将来的に、他の製品でアイデンティティ・コネクタを再利用できます。
4.2 ICFアーキテクチャの概要
アイデンティティ・コネクタにより、Oracle Identity Managerが企業内のターゲット・システムでユーザーのプロビジョニングおよびリコンシリエーションの処理を実行できるようになります。ICFを使用すると、Oracle Identity Managerなどのコール側アプリケーションがコネクタの実装から切り離されます。同様に、コネクタの実装がコール側アプリケーションから切り離されます。同じコネクタ実装を複数の異なるコール側アプリケーションと連携させることができます。
この項では、ICFのアーキテクチャについて説明します。次の項目が含まれます。
4.2.1 Identity Connector Frameworkのデプロイメント
ICF APIおよびSPIは、Oracle Identity Managerとターゲット・システムの間に位置します。
API実装では、必ず、SPI Search処理によって返された結果が後処理されます。コネクタ・バンドルによってすべてのフィルタ・タイプが実装されるわけではない場合、またはフィルタ・タイプがすべての属性に対して適切に実装されるわけではない場合、これがSPI実装の二重チェックになります。SPI Searchの実装によって、指定したタイプのすべてのオブジェクトが返される場合、API実装によって、指定したフィルタに一致しないすべてのオブジェクトが破棄されます。API実装における後処理は処理時間とネットワーク帯域幅の面でコスト高になるため、ターゲット・アプリケーションでネイティブにサポートできるすべてのタイプのフィルタ(検索述語や論理演算子)を各コネクタ・バンドルでサポートすると、より効率的です。詳細は、共通クラスのFilterTranslatorを参照してください。
図4-1では、コール側アプリケーションはICF APIのみを認識しています。ICF APIでは各コネクタ・バンドルに専用のクラスローダーが割り当てられるため、コネクタ・バンドル(SPI)の実装におけるクラスやライブラリにコール側アプリケーションは公開されません。バンドル・クラスローダーは、バンドル間を確実に分離するだけでなく、バンドルされたライブラリを対象のコネクタ・バンドルのみに公開して、依存関係による競合を防止する役割も担います。
4.2.2 ICFとコネクタ・バンドルの互換性
新しいバージョンのICFには、既存のコネクタ・バンドルとの下位互換性があります。
図4-2に、ICFの下位互換性を示します。新しいバンドルをデプロイしても、既存のバンドルには影響しません。また、新しいバージョンのICFには、一般に既存のバンドルとの下位互換性があります。したがって、すべてのコネクタは、新しいバージョンのフレームワークで作業する必要があります。
4.2.3 同じターゲットの複数のバージョンをサポートするデプロイメント方法
ICFのデプロイメント方法では、同じターゲットの複数のバージョンがサポートされます。
図4-3は、ICFのデプロイメント方法を示しています。フレームワークでは、LCMでのコネクタのクローニングをサポートしており、同じターゲットの複数のバージョンをサポートします。また、フレームワークは接続プーリングもサポートします。
4.2.4 コネクタ・サーバーのリモート・システム・フレームワーク
コネクタ・サーバーのリモート・システム・フレームワークにより、ターゲットがコネクタ・バンドルに対してローカルであってもリモートであっても、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。
図4-4は、リモート・システムにインストールされたフレームワークを示しています。これにより、ターゲットがコネクタ・バンドルに対してローカルでもリモートでも、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。これは、アプリケーション内でコネクタ・バンドルが直接実行できない場合に必要で、ICFにより、アプリケーションが外部的にデプロイされたバンドルと通信できるようになります。また、コネクタ・アーティファクトは、ローカル・システムとリモート・システムで同じにできます。
4.2.5 ICFフレームワーク
ICFフレームワークにより、Oracle Identity ManagerとOracle Waveset (OW)のコネクタを単一のコネクタにまとめ、両方の利点を活用できます。
図4-5は、ICFフレームワークを示しています。
4.3 ICF APIの使用
org.identityconnectors.framework.apiパッケージには、ICF APIが含まれています。Oracle Identity Managerでは、このAPIを使用して、コネクタ実装をコールします。このAPIは、サポートされている処理に関係なく、実装されているコネクタに関して一貫した外観を提供します。
次の各項では、これらのインタフェースおよびクラスについて説明します。
4.3.1 ConnectorInfoManagerFactoryクラス
ConnectorInfoManagerFactoryクラスは、Oracle Identity Managerが一連のバンドルからコネクタ・クラスをロードすることを可能にします。
静的なgetInstanceメソッドは、ConnectorInfoManagerFactoryタイプのオブジェクトを返します。このオブジェクトを使用して、ConnectorInfoManagerへの参照を取得できます。(詳細は、ConnectorInfoManagerインタフェースを参照してください。)次に、ConnectorInfoManagerFactoryの実装の例を示します。
//create ConnectorInfoManagerFactory ConnectorInfoManagerFactory cInfoManagerFactory = ConnectorInfoManagerFactory.getInstance();
4.3.2 ConnectorInfoManagerインタフェース
ConnectorInfoManagerインタフェースは、ConnectorInfoインスタンスのリストを管理します。各インスタンスがアイデンティティ・コネクタを表します。
ConnectorInfoManagerFactoryに対してgetLocalManagerメソッドをコールすると、ConnectorInfoManagerが取得され、それにバンドルURLのリストが渡されます。ConnectorInfoManagerは、ConnectorInfoManagerFactoryに対してgetRemoteManagerメソッドをコールすることによっても取得できます。getRemoteManagerメソッドは、コネクタ・サーバーにデプロイされたコネクタに関する情報を取得するために使用されるRemoteFrameworkConnectionInfoandのインスタンスを受け入れます。
次の例では、cInfoManagerFactoryはConnectorInfoManagerFactoryのインスタンスであり、bundleURLはバンドルURL (JARバンドルまたはそれを解凍した内容で構成されるディレクトリを指すURL)のリストです。
//get the ConnectorInfoManager ConnectorInfoManager cInfoManager = cInfoManagerFactory.getLocalManager(bundleURL);
4.3.3 ConnectorKeyクラス
ConnectorKeyは、インストール環境内でConnectorインスタンスを一意に識別します。
ConnectorKeyクラスには、ConnectorInfoインタフェースの例に示すように、bundleName (コネクタ・バンドルの名前)、bundleVersion (コネクタ・バンドルのバージョン)およびconnectorName (コネクタ・バンドルの名前)を指定します。
//get the ConnectorKey reference ConnectorKey flatFileConnectorKey = new ConnectorKey(bundleName, bundleVersion, connectorName);
4.3.4 ConnectorInfoインタフェース
ConnectorInfoインタフェースは、特定のアイデンティティ・コネクタに関する情報を格納します。格納されるのは、特定のアイデンティティ・コネクタに関する表示名、キーおよびメッセージの詳細です。
次に、ConnectorInfoを実装する方法の例を示します。
//get the ConnectorInfo ConnectorInfo info = cInfoManager.findConnectorInfo(flatFileConnectorKey);
例では、cInfoManagerがConnectorInfoManagerであり、flatFileConnectorKeyがアイデンティティ・コネクタ・キーです。
4.3.5 APIConfigurationインタフェース
APIConfigurationインタフェースは、SPI側とAPI側の両方の構成プロパティを示します。
getConfigurationPropertiesメソッドは、コネクタの構成実装に基づいてConfigurationPropertiesインスタンスを返し、このインスタンスはデフォルトに初期化されます。その後、コール元は必要に応じてプロパティを変更できます。次に、この例を示します。
APIConfiguration apiConfig = info.createDefaultAPIConfiguration();
4.3.6 ConfigurationPropertiesインタフェース
ConfigurationPropertiesインタフェースは、SPI構成をカプセル化し、リフレクションを使用して、アプリケーションで操作できる個々のプロパティを識別します。
次の例の定義に従って、setPropertyValueメソッドを使用してアイデンティティ・コネクタのすべての構成プロパティを設定します。
public void setPropertyValue (java.lang.String name, java.lang.Object value)
次に、ConfigurationPropertiesインタフェースの実装の例を示します。
//get the default APIConfiguration ConfigurationProperties flatFileConfigProps = apiConfig.getConfigurationProperties();
4.3.7 ConnectorFacadeFactoryクラス
ConnectorFacadeFactoryクラスは、アプリケーションがコネクタ・インスタンスを取得したり、コネクタ・インスタンスのプールを管理することを可能にします。
次に、ConnectorFacadeFactoryの定義の例を示します。
//get a reference to ConnectorFacadeFactory ConnectorFacadeFactory facadeFactory = ConnectorFacadeFactory.getinstance();
4.3.8 ConnectorFacadeインタフェース
ConnectorFacadeインタフェースは、ターゲット・システムでAPI側の特定のアイデンティティ・コネクタを表すことによってアイデンティティ・コネクタ処理を呼び出すために使用されます。
次に、ConnectorFacadeの実装の例を示します。
//create a ConnectorFacade (nothing but a reference to Connector on SPI side) ConnectorFacade connectorFacade = facadeFactory.newInstance(apiConfig)
4.4 ICF SPIの概要
開発者は、ICF SPIを実装してアイデンティティ・コネクタを作成します。ICF SPIは多数のインタフェースで構成されますが、開発者が実装する必要があるのは、ターゲット・システムでサポートされているインタフェースのみです。SPIは、さらに必須インタフェース、処理インタフェースおよび機能ベースのインタフェースに分類できます。
必須インタフェースは、サポートされている処理に関係なく実装する必要があり、コネクタの作成やターゲット・システムとの接続の維持に利用されるのに対し、処理インタフェースはコネクタで各種処理をサポートするために利用されます。機能ベースのインタフェースは、ICFでサポートされている特定の機能に対応しています。
詳細は、次の各項を参照してください。
4.4.1 必須インタフェースの実装
org.identityconnectors.framework.spi.Connectorおよびorg.identityconnectors.framework.spi.Configurationインタフェースの実装を提供するには、すべてのアイデンティティ・コネクタが必要です。
これらの2つのインタフェースは、ターゲット・システムとのアイデンティティ・コネクタを宣言し、初期化します。詳細は、次の各項を参照してください。
4.4.1.1 org.identityconnectors.framework.spi.Connectorインタフェース
これはアイデンティティ・コネクタを宣言するためのメイン・インタフェースです。コネクタの多くは、接続が必要になったときにターゲット・システムとの接続を確立し、処理が終了したら接続を解除し、使用していたリソースをすべて解放します。インタフェースには、この目的のためにinitとdisposeのライフサイクル・メソッドが用意されています。
ノート:
コネクタ実装には、configurationClassおよびdisplayNameKeyの情報を提供することによって、org.identityconnectors.framework.spi.ConnectorClassタイプでアノテーションを付ける必要があります。displayNameKeyは、Messages.propertiesファイルに定義されたキーにする必要があります。
すべてのコネクタ実装に@ConnectorClassというアノテーションを付ける必要があります。ICFではコネクタ・バンドル内の最上位にあるすべての.classファイルをスキャンし、@ConnectorClassというアノテーションが付いたクラスを探すため、このアノテーションは必須です(これにより、バンドルに定義されたコネクタは自動的に検出されます)。このアノテーションには、次の要素が必要です。
-
configurationClass: このコネクタ用の構成クラス。このクラスにはターゲットに関するすべての情報が保持され、コネクタはこの情報を使用してターゲットに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行できます。構成クラスを実装する方法の詳細は、org.identityconnectors.framework.spi.Configurationインタフェースの項を参照してください。
-
displayNameKey: メッセージ・カタログに存在する必要がある表示名キー。
次に、コネクタ実装のサンプルを示します。
/** * 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{
説明:
-
CreateOp: コネクタがターゲット・システムにエンティティを作成できるようにします。
-
DeleteOp: コネクタがターゲット・システムのエンティティを削除できるようにします。
-
SearchOp: コネクタがターゲット・システムのエンティティを検索できるようにします。
-
UpdateOp: コネクタがターゲット・システムの既存のエンティティを更新できるようにします。
詳細は、処理インタフェースの実装を参照してください。
4.4.1.2 コネクタ・メソッドの実装
次の各項では、コネクタ・メソッドを実装する方法を例示する情報とコード例を示します。
ノート:
コネクタ実装に関する完全なコードは、フラット・ファイル・コネクタの開発を参照してください。
4.4.1.2.1 initメソッドの実装
initメソッドは、コネクタを初期化します。コネクタは、@ConnectorClassというアノテーションが付いた構成インスタンスを使用して自分自身を初期化します。initメソッドには、引数として構成オブジェクトを指定します。構成オブジェクトには、コネクタがターゲット・システムに接続するために必要なすべての情報が保持されています。
次に、JDK 1.8でインタフェースのinitメソッドを実装する方法の例を示します。
ノート:
このドキュメントで紹介されているすべてのコード例において、JDK 1.8でインタフェースを実装するメソッドが使用されています。
@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には含まれていません。これらのクラスの実装は、フラット・ファイル・コネクタの開発に示しています。
initメソッドの実装では、次の処理が実行されます。
-
ターゲット・システムの構成情報を格納します。これは後で処理を実行するときに使用できます。
-
プロビジョニングおよびリコンシリエーションの処理を実行するときに使用されるすべてのサポート・クラスを初期化します。
4.4.1.2.2 disposeメソッドの実装
disposeメソッドは、このコネクタ・インスタンスによって使用されていたリソースをすべて解放します。メソッドがコールされると、コネクタ・インスタンスが破棄され、使用できなくなります。次に、dispose
メソッドを実装する方法の例を示します。
/** * Disposes any resource used by the connector. */ @Override public void dispose() { //close any open FileReader or FileWriter instances. //close connection with the target //close connection if any with database }
4.4.1.2.3 getConfigurationメソッドの実装
getConfigurationメソッドは、initメソッドの使用時にコネクタに渡された構成インスタンスを返します。次に、getConfigurationメソッドを実装する方法の例を示します。
/** * returns the Configuration of this connector */ @Override public Configuration getConfiguration() { return this.flatFileConfig; }
ノート:
コンポーネントは、初期化後に構成インスタンスにアクセスできる必要がある場合があります。これはアクセッサ・メソッドgetConfiguration()によってサポートされています。
4.4.1.3 org.identityconnectors.framework.spi.Configurationインタフェース
このインタフェースの実装は、コネクタの構成をカプセル化します。構成実装にはターゲット・システムに関して必要なすべての情報が保持され、コネクタ実装はこの情報を使用してターゲット・システムに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行します。実装には、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も用意されています。
次に、構成の実装を示します。
/** * Configuration implementation for the flat file connector. */ public class FlatFileConfigurationImpl extends AbstractConfiguration{
4.4.1.4 構成メソッドの実装
構成実装では、次のメソッドの実装を提供する必要があります。
4.4.1.4.1 validate()メソッド
validateメソッドは、すべての必須プロパティの値が設定されていることをチェックします。また、構成プロパティの値がすべて有効であることを検証します。言い換えると、構成プロパティのすべての値が期待される範囲内にあり、期待される形式になっていることを検証します。構成が有効でない場合、実装によって最も固有のRuntimeExceptionが生成されます。固有の例外が利用不可の場合、実装ではConfigurationExceptionをスローできます。次に、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)に依存します。完全な実装は、フラット・ファイル・コネクタの開発に示しています。
4.4.1.4.2 setConnectorMessages()メソッド
setConnectorMessagesメソッドは、org.identityconnectors.framework.common.objects.ConnectorMessagesメッセージ・カタログ・インスタンスを設定し、コネクタがメッセージをローカライズすることを可能にします。次に、setConnectorMessagesメソッドの定義の例を示します。
public final void setConnectorMessages(ConnectorMessages messages) {_connectorMessages = messages;}
4.4.2 機能ベースのインタフェースの実装
PoolableConnectorおよびAttributeNormalizerインタフェースは、アイデンティティ・コネクタ・プーリングと属性の正規化をそれぞれ有効にする場合に使用します。
この項では、PoolableConnectorおよびAttributeNormalizerインタフェースについて説明します。次の項目が含まれます。
4.4.2.1 org.identityconnectors.framework.spi.PoolableConnectorインタフェース
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メソッドが用意されています。次に、フラット・ファイル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インタフェースを実装するには、org.identityconnectors.framework.spi.Connectorインタフェースで説明したすべてのメソッドとともにcheckAliveメソッドの実装を提供します。checkAliveメソッドは、コネクタ・インスタンスが動作しているかどうかを確認するメソッドであり、ターゲット・システムでの操作に使用できます。checkAliveは頻繁にコールされる可能性があるので、開発者は、実装が高速であることを確認する必要があります。メソッドは、コネクタが動作しなくなったときに、固有のRuntimeException(利用可能な場合)をスローする必要があります。次に、checkAliveメソッドを実装する方法の例を示します。
/** * Checks if this connector is alive, if not throws a RuntimeException */ @Override public void checkAlive() { //check if the connector is still connected to target }
4.4.2.2 org.identityconnectors.framework.spi.AttributeNormalizerインタフェース
このインタフェースは、コネクタに渡される属性を正規化する必要がある場合に、実装する必要があります。正規化では、表示、消費または比較用に値が標準形式に変換されます。たとえば、正規化では、テキスト値を大文字または小文字に変換したり、空白の切捨てを行ったり、DNの要素を特定の方法で並べることができます。
インタフェースには、この目的のためにnormalizeAttributeメソッドが定義されています。このメソッドには、引数としてObjectClassと正規化対象の属性を指定し、戻り値は正規化した属性になります。属性の正規化は、次のような様々な項目を処理するときに適用されます。
-
SearchOpに渡されるフィルタ
-
SearchOpから返される結果
-
SyncOpから返される結果
-
UpdateAttributeValuesOpに渡される属性
-
UpdateAttributeValuesOpから返されるUid
-
UpdateOpに渡される属性
-
UpdateOpから返されるUid
-
CreateOpに渡される属性
-
CreateOpから返されるUid
-
DeleteOpに渡されるUid
次に、normalizeAttributeメソッドの定義の例を示します。
public Attribute normalizeAttribute (ObjectClass oClass, Attribute attribute) { if (attribute instanceof Uid) { return new Uid(LdapUtil.createUniformUid((String)newValues.get(0), configuration.getSuffix())); } }
4.4.3 処理インタフェースの実装
org.identityconnectors.framework.spi.operationsパッケージに属する処理インタフェースごとに、コネクタがターゲット・システムで実行できるアクションが定義されています。
この項では、処理インタフェースについて説明します。次の項目が含まれます。
4.4.3.1 処理インタフェースについて
処理インタフェースごとに、コネクタがターゲット・システムで実行できるアクション(サポートされている場合)が定義されています。処理インタフェースは、org.identityconnectors.framework.spi.operationsパッケージに属しています。これらの処理インタフェースの名前は次のとおりですが、各インタフェースの詳細は後続の項を参照してください。
-
AuthenticateOp
-
CreateOp
-
DeleteOp
-
ResolveUsernameOp
-
SchemaOp
-
ScriptOnConnectorOp
-
ScriptOnResourceOp
-
SearchOp<T>SyncOp
-
TestOp
-
UpdateAttributeValuesOp
-
UpdateOp
4.4.3.2 SchemaOpインタフェースの実装
SchemaOpインタフェースを実装すると、ターゲット・システムで処理できるオブジェクトをコネクタが表すことが可能になります。コネクタから返されるスキーマは、コネクタが管理用に公開するオブジェクト・クラスを表します。各オブジェクト・クラスは、名前、説明および一連の属性定義を持ちます。各属性定義には、名前、構文の他、複数値、単一値、読取り可能、書込み可能などのプロパティを表す特定のフラグが含まれます。
コネクタから返されるスキーマは、コネクタが公開する各タイプのオブジェクトの属性を表します。内部表現からこのスキーマ形式への変換が必要になる場合もあります。それ以外に、スキーマは、ターゲットAPIへのコールを通じてのみネイティブに利用できる情報を属性として表す場合もあります。SPI実装でネイティブ表現とそれに対応するConnectorObjectの間のマッピングがどのように行われるかに関係なく、スキーマはメタデータを提供し、このメタデータを通じて、各タイプ(objectClass)のConnectorObject内に含まれるものとクライアントが想定する情報を表します。
このインタフェースを実装するには、次の例の定義に従って、schemaメソッドの実装を提供します。
public Schema 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が含まれないようにする必要があります。
4.4.3.3 CreateOpインタフェースの実装
CreateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの作成が可能になります。このインタフェースを実装するには、次の例に示すように、create()メソッドの実装を提供します。
public Uid create (ObjectClass objectClass, Set<Attribute> attributes, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、一連のオブジェクト属性および処理オプションを指定します。実装では、渡されたオブジェクト属性とObjectClassで定義されたオブジェクト・タイプを使用して、ターゲット・システムにオブジェクトを作成します。ObjectClass引数では、作成対象のオブジェクトのクラスを指定します。作成対象のオブジェクトのクラスは、作成処理に対する入力の1つです。次の例に示すように、ObjectClassは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を使用して、作成されたオブジェクトを参照できます。
4.4.3.4 DeleteOpインタフェースの実装
DeleteOpインタフェースを実装すると、ターゲット・システムからのオブジェクトの削除が可能になります。このインタフェースを実装するには、次の例の定義に従って、deleteメソッドの実装を提供します。
public void delete (ObjectClass objectClass, Uid uid, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、ターゲット・システムから削除するオブジェクトのUidおよび処理オプションを指定します。実装では、指定されたUidで識別されるオブジェクトをターゲット・システムから削除します。オブジェクトがターゲット・システムに存在しない場合は、org.identityconnectors.framework.common.exceptions.UnknownUidExceptionが生成されます。次に、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のサブクラスを生成します。詳細は、Identity Connector Framework Java APIリファレンスを参照してください。
4.4.3.5 SearchOpインタフェースの実装
SearchOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの検索が可能になります。
この項では、SearchOpインタフェースを実装する方法について説明します。次の項目が含まれます。
4.4.3.5.1 SearchOpインタフェースの実装について
SearchOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの検索が可能になります。
この場合、検索処理では次のことが行われます。
-
一般に指定される検索条件を実装するためのネイティブ・フィルタが作成されます。
-
実際の問合せが実行されます。
SPIでこれらのメソッドを実装すると、APIで検索をサポートできるようになります。APIでは、指定されたフィルタ条件をネイティブ検索条件に変換することなどによって、コネクタで実行されないすべてのフィルタを(結果の後処理を通じて)実行します。
このインタフェースを実装するには、createFilterTranslatorメソッドおよびexecuteQueryメソッドの実装を提供します。
4.4.3.5.2 createFilterTranslatorメソッドの実装
createFilterTranslatorメソッドは、API側から渡されたICFフィルタ・オブジェクトをネイティブ問合せに変換するFilterTranslator実装のインスタンスを返します。変換後、ICFは問合せをexecuteQueryメソッドに渡します。次に、createFilterTranslatorメソッドの定義の例を示します。
public FilterTranslator createFilterTranslator (ObjectClass oClass, OperationsOptions options)
ノート:
NULLの戻り値は許可されていません。
次に、createFilterTranslatorメソッドの実装の例を示します。
@Override public FilterTranslator<Map<String, String>> createFilterTranslator (ObjectClass arg0, OperationOptions arg1) { return new ContainsAllValuesImpl() { }; }
この例では、単一タイプの検索述語(ContainsAllValues)のみがサポートされています。ContainsAllValuesImplの実装の例は、AbstractFilterTranslatorの実装を参照してください。ContainsAllValuesの実装では、条件の形式をネイティブ形式に変換します。属性Aには、すべての値V(1)、V(2) ... V(N)が含まれます。
org.identityconnectors.framework.common.objects.filter.FilterTranslatorの詳細は、共通クラスを参照してください。
4.4.3.5.3 executeQueryメソッドの実装
executeQueryメソッドは、FilterTranslatorの実装によって生成されるすべての問合せに対してコールされます(createFilterTranslatorメソッドの実装を参照)。次の例に示すように、ObjectClass (アカウントやグループなど)、問合せ、見つかったオブジェクトを処理するためにコールバックとして使用されるResultsHandlerのインスタンスおよび処理オプションを指定します。
public void executeQuery (ObjectClass oClass, T query, ResultsHandler handler, OperationOptions options)
executeQueryメソッドの実装では、渡された問合せを使用してターゲット・オブジェクトを検索し、見つかったターゲット・オブジェクトごとにConnectorObjectのインスタンスを作成し、ResultsHandlerを使用してConnectorObjectを処理します。ConnectorObjectは、ターゲット・リソース・オブジェクトのICF表現です。ObjectClass、Uid、名前、一連の属性などの情報が保持されます。ConnectorObjectは検索の中心となります。executeQueryは、ConnectorObjectをストリームとしてResultsHandlerに送り、そしてクライアントに送ります。次に、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; } } }
4.4.3.6 UpdateOpインタフェースの実装
UpdateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの更新が可能になります。このインタフェースを実装するには、次の例の定義に従って、updateメソッドの実装を提供します。
public Uid update(ObjectClass oClass, Uid uid, Set<Attribute> attributes, OperationOptions options)
このメソッドには、ObjectClass(アカウントやグループなど)、更新対象のオブジェクトのUid、更新対象の一連のオブジェクト属性および処理オプションを指定します。実装では、ターゲット・システム上でUidによって識別されるオブジェクトを新しい属性値で更新します。Uidによって識別されるオブジェクトがターゲット・システムに存在しない場合は、UnknowUidExceptionが生成されます。次に、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); }
4.4.4 共通クラス
最も重要なICFクラスは、org.identityconnectors.framework.common.objects.Attribute、org.identityconnectors.framework.common.objects.Uid、org.identityconnectors.framework.common.objects.ObjectClass、org.identityconnectors.framework.common.objects.ConnectorObject、org.identityconnectors.common.security.GuardedString、org.identityconnectors.framework.common.objects.filter.FilterTranslatorおよびorg.identityconnectors.framework.common.objects.ResultsHandlerです。
前の各項で示したように、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)
詳細は、SearchOpインタフェースの実装を参照してください。
-
-
org.identityconnectors.framework.common.objects.ResultsHandler
これは、処理で1つ以上の結果が返される場合のコールバック・インタフェースです。サブクラスはメソッドを処理するための実装を提供する必要があるのに対し、コール元は結果に対する処理を決めることができます。現在、これはSearchOpインタフェースでのみ使用されます。詳細は、SearchOpインタフェースの実装を参照してください。
4.5 アイデンティティ・コネクタ・バンドルの拡張
アイデンティティ・コネクタ・バンドルは、特定のターゲット・システムに固有の実装です。
バンドルは、アイデンティティ・コネクタがターゲット・システムに接続し、処理を実行するために必要なすべてのファイルを含む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/*(特定のデータベース・ドライバおよびライブラリ(必要に応じて))
4.6 アイデンティティ・コネクタ・サーバーの使用
アイデンティティ・コネクタ・サーバーは、Java (tm)およびMicrosoft .NET Frameworkアプリケーションに対応しています。
この項では、アイデンティティ・コネクタ・サーバーと各タイプのアイデンティティ・コネクタ・サーバーの使用方法について説明します。次の項目が含まれます。
ヒント:
どちらのコネクタ・サーバーを構成する場合も、次の情報(インストール時に定義)を準備してください。
-
ホスト名およびIPアドレス
-
コネクタ・サーバー・ポート
-
コネクタ・サーバー・キー
-
SSL有効
4.6.1 アイデンティティ・コネクタ・サーバーについて
アイデンティティ・コネクタ・バンドルがアプリケーション内で直接実行されない場合は、アイデンティティ・コネクタ・サーバーが必要です。ICFアーキテクチャでは、1つ以上のアイデンティティ・コネクタ・サーバーを使用することで、アプリケーションと外部にデプロイされたアイデンティティ・コネクタ・バンドルとの通信が可能になります。
アイデンティティ・コネクタ・サーバーは、Java (tm)およびMicrosoft .NET Frameworkアプリケーションに対応しています。単一のコネクタ・サーバーで複数のICFコネクタをサポートでき、これらのICFコネクタのタイプもそれぞれ異なっていてかまいません。単一のICFコネクタを使用して、複数のターゲットと通信できます。
図4-6に、Oracle Identity ManagerコネクタがICFコネクタを介してリソースと統合される仕組みを示します。
次に、図4-6について説明します。
-
Oracle Identity Managerコネクタは、ターゲット・リソースと直接対話することはありません。かわりに、適切なICFコネクタを介して、作成、読取り、更新、削除および問合せ(CRUDQ)の各処理が実行されます。
-
単一のICFコネクタを使用して、リソース・タイプが同じ複数のリソースに接続できます。図4-6では、LDAP用のICFコネクタを使用して、ローカルLDAPリソースとリモートLDAPリソースの両方に接続しています。
-
.NETコネクタ・サーバーを使用して、.NET ICFコネクタをターゲット・ホストにデプロイします。この方法でActive Directoryリソースが接続されます。
-
Google Apps用のICFコネクタは、インターネット上のGoogle Appsとの接続に使用されます。
-
図には示されていませんが、コネクタ・サーバーではリソース・タイプが異なる複数のICFコネクタをサポートできます。
4.6.2 Javaコネクタ・サーバーの使用
アプリケーションと同じJava仮想マシン(JVM)でJavaコネクタ・バンドルを実行しない場合は、Javaコネクタ・サーバーを使用します。
バンドルを管理対象ターゲット・システムと同じホストにデプロイすると、動作速度が向上するため、このデプロイメントはパフォーマンスの面で有効です。また、Javaコネクタ・サーバーを使用すると、JNIベースのコネクタの障害が原因でアプリケーションJVMがクラッシュする可能性を排除できます。
Javaコネクタ・サーバーの使用方法については、次の各項で説明します。
4.6.2.2 ConnectorServer.propertiesファイル内のプロパティ
表4-1は、ConnectorServer.propertiesファイル内のプロパティのリストです。
表4-1 ConnectorServer.propertiesファイル内のプロパティ
プロパティ | 説明 |
---|---|
connectorserver.port |
SSLおよび非SSLコネクタ・サーバーの両方のポートを示す共有プロパティです。connectorserver.usesslプロパティを SSLおよび非SSLのデフォルトのポート番号は |
connectorserver.bundleDir |
コネクタ・バンドルがデプロイされるディレクトリ。デフォルト値は |
connectorserver.libDir |
依存ライブラリを配置するディレクトリ。デフォルト値は |
connectorserver.usessl |
trueに設定すると、Javaコネクタ・サーバーでSSLを使用してセキュアな通信が実現されます。デフォルト値は trueを指定する場合は、Javaコネクタ・サーバーの起動時にコマンド行で次のオプションを使用してください。
|
connectorserver.ifaddress |
バインド・アドレス。このプロパティを設定する場合は、必要に応じてファイル内でプロパティのコメントアウトを解除してください。バインド・アドレスは、コンピュータにその他のNICが取り付けられている場合に役立ちます。 |
connectorserver.key |
Javaコネクタ・サーバー・キー。 |
4.6.2.3 Microsoft WindowsでのJavaコネクタ・サーバーの実行
Microsoft WindowsでJavaコネクタ・サーバーを実行するには、次のようにConnectorServer.batスクリプトを使用します。
4.6.2.4 ConnectorServer.batスクリプトでサポートされているオプション
表4-2に、ConnectorServer.batスクリプトでサポートされているオプションを示します。
表4-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サービスがアンインストールされます。 |
4.6.2.5 SolarisおよびLinuxでのJavaコネクタ・サーバーの実行
SolarisおよびLinuxでJavaコネクタ・サーバーを実行するには、次のようにconnectorserver.shスクリプトを使用します。
4.6.2.6 connectorserver.shスクリプトでサポートされているオプション
表4-3に、connectorserver.shスクリプトでサポートされているオプションを示します。
表4-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プロパティにキーのハッシュ値を格納します。 |
4.6.2.7 Javaコネクタ・サーバーへのアイデンティティ・コネクタのインストール
この項では、Javaコネクタ・サーバーにJavaコネクタ・バンドルをデプロイする手順について説明します。
- Javaコネクタ・サーバー・ディレクトリのbundlesディレクトリに移動します。
- Javaコネクタ・バンドルJARをbundlesディレクトリにコピーします。
- アイデンティティ・コネクタで必要になるサード・パーティJARファイルが存在する場合は、それらをlibディレクトリに追加します。
- Javaコネクタ・サーバーを再起動します。
4.6.3 .NETコネクタ・サーバーの使用
アプリケーションがJavaで記述されており、コネクタ・バンドルがC#で記述されている場合は、.NETコネクタ・サーバーを使用すると便利です。
Java Platform, Enterprise Edition (JEE (tm))アプリケーションではC#クラスをロードできないため、.NETコネクタ・サーバーの配下にC#バンドルをデプロイできます。これにより、Javaアプリケーションはネットワーク上で.NETコネクタ・サーバーと通信できるようになります。.NETコネクタ・サーバーは、C#バンドルへの認証されたアプリケーション・アクセスを実現するプロキシとして機能します。次の各項では、追加情報を示します。
4.6.3.1 .NETコネクタ・サーバーのインストール
.NETコネクタ・サーバー12.2.1.3.0を実行するための要件は次のとおりです:
-
Microsoft Windows Server 2003、2008、2012、2016または2019
-
Microsoft .NET Framework 4.5以上
追加要件の有無は、特定の.NETアイデンティティ・コネクタのドキュメントを参照してください。
4.6.3.3 .NETコネクタ・サーバーのアップグレード
12.2.1.3.0バージョンの.NETコネクタ・サーバー・パックでは、connectorserver.protocol
プロパティを使用して、Oracle Identity Managerと.NETコネクタ・サーバーの間のSSL通信のプロトコルを選択できます。このプロパティのサポートされている値は、Tls
、Tls11
およびTls12
です。ここで、Tls
はTLS 1.0プロトコルを示し、Tls11
はTLS 1.1プロトコルを示し、Tls12
はTLS 1.2プロトコルを示します。このプロパティのデフォルト値はTls
で、TLS 1.0プロトコルを示します。
.NETコネクタ・サーバーをアップグレードするには:
4.6.3.4 トレース設定の構成
コネクタ・サーバーでは、標準の.NETトレース・メカニズムが使用されます。トレース設定は、connectorserver.exe.config構成ファイルに定義されています。次に、定義する方法の例を示します。
<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ドキュメントを参照してください。
4.6.3.5 .NETコネクタ・サーバーの実行
.NETコネクタ・サーバーを実行する最適な方法は、Windowsサービスとして実行することです。インストール時に、コネクタ・サーバーはWindowsサービスとしてインストールされます。これが環境に適さない場合は、コマンド・プロンプトで/installまたは/uninstall引数を使用して、コネクタ・サーバーをWindowsサービスとしてインストールまたはアンインストールできます。
コネクタ・サーバーを対話形式で実行するには、コマンド・プロンプトを開き、.NETコネクタ・サーバーがインストールされているディレクトリに移動して、次のコマンドを実行します。
ConnectorServer.exe /run