4 Identity Connector Frameworkの理解

アイデンティティ・コネクタは、Oracle Identity Managerをアプリケーション、ディレクトリおよびデータベースの外部ストアとリンクする目的で開発されたコンポーネントです。

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-1 Identity Connector Frameworkのデプロイメント

図4-1の説明が続きます
「図4-1 Identity Connector Frameworkのデプロイメント」の説明

4.2.2 ICFとコネクタ・バンドルの互換性

新しいバージョンのICFには、既存のコネクタ・バンドルとの下位互換性があります。

図4-2に、ICFの下位互換性を示します。新しいバンドルをデプロイしても、既存のバンドルには影響しません。また、新しいバージョンのICFには、一般に既存のバンドルとの下位互換性があります。したがって、すべてのコネクタは、新しいバージョンのフレームワークで作業する必要があります。

図4-2 ICFとコネクタ・バンドルの互換性

図4-2の説明が続きます
「図4-2 ICFとコネクタ・バンドルの互換性」の説明

4.2.3 同じターゲットの複数のバージョンをサポートするデプロイメント方法

ICFのデプロイメント方法では、同じターゲットの複数のバージョンがサポートされます。

図4-3は、ICFのデプロイメント方法を示しています。フレームワークでは、LCMでのコネクタのクローニングをサポートしており、同じターゲットの複数のバージョンをサポートします。また、フレームワークは接続プーリングもサポートします。

図4-3 同じターゲットの複数のバージョンをサポートするデプロイメント方法

図4-3の説明が続きます
「図4-3 同じターゲットの複数のバージョンをサポートするデプロイメント方法」の説明

4.2.4 コネクタ・サーバーのリモート・システム・フレームワーク

コネクタ・サーバーのリモート・システム・フレームワークにより、ターゲットがコネクタ・バンドルに対してローカルであってもリモートであっても、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。

図4-4は、リモート・システムにインストールされたフレームワークを示しています。これにより、ターゲットがコネクタ・バンドルに対してローカルでもリモートでも、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。これは、アプリケーション内でコネクタ・バンドルが直接実行できない場合に必要で、ICFにより、アプリケーションが外部的にデプロイされたバンドルと通信できるようになります。また、コネクタ・アーティファクトは、ローカル・システムとリモート・システムで同じにできます。

図4-4 コネクタ・サーバーのリモート・システム・フレームワーク

図4-4の説明が続きます
「図4-4 コネクタ・サーバーのリモート・システム・フレームワーク」の説明

4.2.5 ICFフレームワーク

ICFフレームワークにより、Oracle Identity ManagerとOracle Waveset (OW)のコネクタを単一のコネクタにまとめ、両方の利点を活用できます。

図4-5は、ICFフレームワークを示しています。

図4-5 ICFフレームワーク

図4-5の説明が続きます
「図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.1.4.3 getConnectorMessages()メソッド

getConnectorMessagesメソッドは、setConnectorMessagesメソッドによって設定されたConnectorMessagesを返します。次に、getConnectorMessagesメソッドの定義の例を示します。

public final ConnectorMessages getConnectorMessages() {return _connectorMessages;}

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 ICFコネクタおよびコネクタ・サーバー

図4-6の説明が続きます
「図4-6 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.1 Javaコネクタ・サーバーのインストールおよび構成

Javaコネクタ・サーバーをインストールおよび構成するには:

  1. Javaコネクタ・サーバーをインストールするコンピュータに新しいディレクトリを作成します。この項では、このディレクトリをCONNECTOR_SERVER_HOMEとしています。
  2. ステップ1で作成した新しいディレクトリにJavaコネクタ・サーバー・パッケージを解凍します。Javaコネクタ・サーバーは、次のURLにあるOracle Technology Network Webサイトからダウンロードできます。
  3. conf/ディレクトリにあるConnectorServer.propertiesファイルで、デプロイメントで必要になるプロパティを設定します。ConnectorServer.propertiesファイル内のプロパティの詳細は、ConnectorServer.propertiesファイル内のプロパティを参照してください。
  4. ConnectorServer.propertiesファイル内のプロパティを次のように設定します。
  5. confディレクトリにはlogging.propertiesファイルもあり、デプロイメントで必要になる場合は編集できます。
4.6.2.2 ConnectorServer.propertiesファイル内のプロパティ

表4-1は、ConnectorServer.propertiesファイル内のプロパティのリストです。

表4-1 ConnectorServer.propertiesファイル内のプロパティ

プロパティ 説明

connectorserver.port

SSLおよび非SSLコネクタ・サーバーの両方のポートを示す共有プロパティです。connectorserver.usesslプロパティをtrueに設定した場合、コネクタ・サーバーによって同じポートが使用されてセキュアなチャネルがリスニングされます。

SSLおよび非SSLのデフォルトのポート番号は8759です。コネクタ・サーバーのデフォルトのポート(SSLまたは非SSL)を変更するには、ConnectorServer.propertiesファイルの新しいポート番号を使用してconnectorserver.portプロパティを更新します。

connectorserver.bundleDir

コネクタ・バンドルがデプロイされるディレクトリ。デフォルト値はbundlesです。

connectorserver.libDir

依存ライブラリを配置するディレクトリ。デフォルト値はlibです。

connectorserver.usessl

trueに設定すると、Javaコネクタ・サーバーでSSLを使用してセキュアな通信が実現されます。デフォルト値はfalseです。

trueを指定する場合は、Javaコネクタ・サーバーの起動時にコマンド行で次のオプションを使用してください。

  • -Djavax.net.ssl.keyStore

  • -Djavax.net.ssl.keyStoreType (オプション)

  • -Djavax.net.ssl.keyStorePassword

connectorserver.ifaddress

バインド・アドレス。このプロパティを設定する場合は、必要に応じてファイル内でプロパティのコメントアウトを解除してください。バインド・アドレスは、コンピュータにその他のNICが取り付けられている場合に役立ちます。

connectorserver.key

Javaコネクタ・サーバー・キー。

4.6.2.3 Microsoft WindowsでのJavaコネクタ・サーバーの実行

Microsoft WindowsでJavaコネクタ・サーバーを実行するには、次のようにConnectorServer.batスクリプトを使用します。

  1. Javaコネクタ・サーバーのインストールおよび構成の説明に従って、デプロイメントに必要なプロパティをConnectorServer.propertiesファイルで設定していることを確認します。
  2. CONNECTOR_SERVER_HOME\binディレクトリに移動し、ConnectorServer.batスクリプトを探します。

    ConnectorServer.batスクリプトでサポートされているオプションの詳細は、ConnectorServer.batスクリプトでサポートされているオプションを参照してください。

  3. Javaコネクタ・サーバーを停止する必要がある場合は、対応するMicrosoft Windowsサービスを停止します。

    ノート:

    connectorserver.batスクリプトを実行すると、次のヒープ・メモリーの問題が発生する場合があります:

    org.identityconnectors.framework.server.impl.ConnectionListener
    processOperationRequest
    
    SEVERE: Java heap space
    
    java.lang.OutOfMemoryError: Java heap space
    
    at
    java.io.BufferedInputStream.fill(BufferedInputStream.java:233)
    
    at
    java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
    
    at
    java.io.BufferedInputStream.read(BufferedInputStream.java:345)
    
    at java.io.DataInputStream.read(DataInputStream.java:149)
    
    at sun.misc.IOUtils.readFully(IOUtils.java:65)
    
    at
    sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:753)
    
    at
    sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
    
    at
    sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
    
    at
    sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:
    70)
    
    at java.security.KeyStore.load(KeyStore.java:1445)
    
    at
    sun.security.ssl.TrustManagerFactoryImpl.getCacertsKeyStore(TrustManagerFactor
    yImpl.java:226)
    
    at
    sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.ja
    va:50)
    
    at
    javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:250)
    
    at
    sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:72)
    
    at javax.net.ssl.SSLContext.init(SSLContext.java:282)

    この問題を回避するには、connectorserver.batスクリプトを編集し、次のように値500m2048mに変更します:

    set JAVA_OPTS=-Xmx2048m
        "-Djava.util.logging.config.file=%CONNECTOR_SERVER_HOME%\conf\logging.properties"
        "-Djava.io.tmpdir=%CONNECTOR_SERVER_HOME%\temp"
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スクリプトを使用します。

  1. Javaコネクタ・サーバーのインストールおよび構成の説明に従って、デプロイメントに必要なプロパティをConnectorServer.propertiesファイルで設定していることを確認します。
  2. CONNECTOR_SERVER_HOME/binディレクトリに移動します。
  3. chmodコマンドを使用して、connectorserver.shスクリプトを実行可能にするための権限を設定します。
  4. connectorserver.shスクリプトを実行します。connectorserver.shスクリプトでサポートされているオプションの詳細は、connectorserver.shスクリプトでサポートされているオプションを参照してください。

    ノート:

    connectorserver.shスクリプトを実行すると、次のヒープ・メモリーの問題が発生する場合があります:

    org.identityconnectors.framework.server.impl.ConnectionListener
    processOperationRequest
    
    SEVERE: Java heap space
    
    java.lang.OutOfMemoryError: Java heap space
    
    at
    java.io.BufferedInputStream.fill(BufferedInputStream.java:233)
    
    at
    java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
    
    at
    java.io.BufferedInputStream.read(BufferedInputStream.java:345)
    
    at java.io.DataInputStream.read(DataInputStream.java:149)
    
    at sun.misc.IOUtils.readFully(IOUtils.java:65)
    
    at
    sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:753)
    
    at
    sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
    
    at
    sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
    
    at
    sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:
    70)
    
    at java.security.KeyStore.load(KeyStore.java:1445)
    
    at
    sun.security.ssl.TrustManagerFactoryImpl.getCacertsKeyStore(TrustManagerFactor
    yImpl.java:226)
    
    at
    sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.ja
    va:50)
    
    at
    javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:250)
    
    at
    sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:72)
    
    at javax.net.ssl.SSLContext.init(SSLContext.java:282)

    この問題を回避するには、connectorserver.shスクリプトを編集し、次のように値500m2048mに変更します:

    exec "$_RUNJAVA" -Xmx2048m
        -D"java.util.logging.config.file=${CONNECTOR_SERVER_HOME}/conf/logging.propert ies"
        -D"java.io.tmpdir=${CONNECTOR_SERVER_TMPDIR}" $JAVA_OPTS_PARAMS \
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秒間待った後もまだプロセスが実行されている場合は、kill -KILLコマンドを使用します。

/stop n -force

Javaコネクタ・サーバーを停止します。最大でn秒間待った後もまだプロセスが実行されている場合は、kill -KILLコマンドを使用します。

/setKey key

Javaコネクタ・サーバー・キーを設定します。connectorserver.shスクリプトでは、ConnectorServer.propertiesファイル内のconnectorserver.keyプロパティにキーのハッシュ値を格納します。

4.6.2.7 Javaコネクタ・サーバーへのアイデンティティ・コネクタのインストール

この項では、Javaコネクタ・サーバーにJavaコネクタ・バンドルをデプロイする手順について説明します。

  1. Javaコネクタ・サーバー・ディレクトリのbundlesディレクトリに移動します。
  2. Javaコネクタ・バンドルJARをbundlesディレクトリにコピーします。
  3. アイデンティティ・コネクタで必要になるサード・パーティJARファイルが存在する場合は、それらをlibディレクトリに追加します。
  4. Javaコネクタ・サーバーを再起動します。
4.6.2.8 SSLを使用したコネクタ・サーバーとの通信

Secure Sockets Layer (SSL)を使用してコネクタ・サーバーと通信するには、次のステップを実行します。

  1. コネクタ・サーバーのシステムにSSL証明書をデプロイします。
  2. SSLソケットを提供するようにコネクタ・サーバーを構成します。
  3. SSLを使用してコネクタ・サーバーと通信するようにアプリケーションを構成します。

    アイデンティティ・コネクタ・サーバーとの接続構成に固有のノートは、ターゲット・システムのマニュアルを参照してください。各SSL対応コネクタ・サーバーとの接続を確立するときにはSSL接続が必要になることをアプリケーションに指示します。さらに、コネクタ・サーバーで使用されるSSL証明書のいずれかが非標準認証局によって発行される場合は、追加の認証局を考慮するようにアプリケーションを構成する必要があります。認証局に関するノートは、該当するマニュアルを参照してください。

    ノート:

    Javaアプリケーションにおいて非標準認証局に関する問題を解決するには、アプリケーションの起動時に次のJavaシステム・プロパティが渡されるようにします。

    • javax.net.ssl.trustStorePassword

      たとえば:

      -Djavax.net.ssl.trustStorePassword=PASSWORD

    • javax.net.ssl.trustStore

      たとえば:

      -Djavax.net.ssl.trustStore=/usr/myApp_cacerts

    また、非標準認証局を標準の${JAVA_HOME}/lib/security/cacertsディレクトリにインポートすることもできます。

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アイデンティティ・コネクタのドキュメントを参照してください。

.NETコネクタ・サーバー12.2.1.3.0をインストールするには:
  1. 次のURLのOracle Technology Networkサイトからコネクタ・サーバー・パッケージ(Connector_Server_122130_dotnet.zip)をダウンロードします。
  2. コネクタ・サーバー・パッケージの内容を抽出し、ServiceInstall-version.msiファイルを探します。

    ノート:

    権限の少ないユーザーではすべてのコネクタ操作を実行できるわけではありません。そのため、.NETコネクタ・サーバーを実行するには、(最小限の権限があるユーザーとして)管理ユーザー・アカウントを使用する必要があります。
  3. ServiceInstall-version.msiファイルを実行し、ウィザードに従って、コネクタ・サーバーをインストールします。ウィザードでは、1ステップずつインストール・プロセスが示されます。完了すると、.NETコネクタ・サーバーがWindowsサービスとして登録されます。
4.6.3.2 .NETコネクタ・サーバーの構成

共通構成には、ポート、トレース、SSL設定およびコネクタ・サーバー・キーが含まれます。

.NETコネクタ・サーバーを構成するには:

  1. Microsoftサービス・コンソールを起動します。

    .NETコネクタ・サーバーが実行している場合は、Windowsサービスを停止することで停止します。

  2. .NETコネクタ・サーバーがインストールされているディレクトリに移動します。デフォルトのディレクトリは、C:\Program Files(x86)\Idenity Connector\Connector Serverです。

    コマンド・プロンプトで次のコマンドを実行します。

    ConnectorServer.exe /setkey NEW_KEY

    このコマンドのNEW_KEYは新しいキーの値です。このキーは、クライアントがこの.NETコネクタ・サーバーに接続するときに必要になります。

  3. .NETコネクタ・サーバーの構成ファイル(ConnectorServer.exe.config)で設定を更新します。これらの設定は、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"/> 
    <add key="logging.proxy" value="false"/>
    <!--Possible protocol values are Tls, Tls11, Tls12 -->
    <add key="connectorserver.protocol" value="Tls">

    よく変更される設定を次に示します。

    • ポート番号: connectorserver.portプロパティは、SSLと非SSL両方のコネクタ・サーバー・ポートを示すキーです。connectorserver.usesslプロパティをtrue に設定した場合、コネクタ・サーバーによって同じポートが使用されてセキュアなチャネルがリスニングされます。SSLおよび非SSLのデフォルトのポート番号は8759です。デフォルトのコネクタ・サーバー・ポートを変更するには、connectorserver.exe.configファイルで新しいポート番号を指定してconnectorserver.portプロパティを更新します。

    • SSL設定: SSLを使用するには、connectorserver.usesslの値をtrueに設定し、connectorserver.certifacatestorenameの値を、信頼証明書を格納する証明書ストアの名前に設定します。コマンド・プロンプトで次のコマンドを実行して、ターゲット・システムの信頼証明書を作成し、証明書ストアに追加します。

      C:\>certutil -f -addstore tlsstore C:\ADSSLCer.cer
      Note: refer the connector guide of respective target system to generate the trust certificate i.e.  C:\ADSSLCer.cer
      

      ノート:

      コマンドで指定した証明書ストアが存在していないことを確認してください。ConnectorServer.exe.Configファイルで指定する証明書ストアには、1つの証明書のみを格納する必要があります。複数の証明書がある場合、.NETコネクタ・サーバーは起動しません。

      次のコマンドを実行して、証明書ストアに含まれる証明書の数を確認します。

      C:\>certutil -viewstoreSTORE_NAME

      さらに、connectorserver.protocolを更新して、SSL通信プロトコル(TLS 1.0、TLS 1.1またはTLS 1.2)を選択します。

    • リスニング・ソケット・バインド: リスニング・ソケット・バインドを変更するには、connectorserver.ifaddressを0.0.0.0以外のアドレスに設定します。

  4. .NETコネクタ・サーバー・インストールの次の構成情報を保存します。この情報は、コネクタ・サーバーのITリソースを構成する際に指定する必要があります。
    • ホスト名またはIPアドレス

    • コネクタ・サーバー・ポート

    • コネクタ・サーバー・キーの値

    • SSLを有効にする必要があるかどうか

  5. .NETコネクタ・サーバーの構成がすべて完了したら、Windowsサービスを再開するか、またはコマンド行インタフェースで次のコマンドを実行して.NETコネクタ・サーバーを再起動します。.NETコネクタ・サーバーがインストールされているディレクトリに移動し、次のコマンドを実行します。
    ConnectorServer.exe /run
4.6.3.3 .NETコネクタ・サーバーのアップグレード

12.2.1.3.0バージョンの.NETコネクタ・サーバー・パックでは、connectorserver.protocolプロパティを使用して、Oracle Identity Managerと.NETコネクタ・サーバーの間のSSL通信のプロトコルを選択できます。このプロパティのサポートされている値は、TlsTls11およびTls12です。ここで、TlsはTLS 1.0プロトコルを示し、Tls11はTLS 1.1プロトコルを示し、Tls12はTLS 1.2プロトコルを示します。このプロパティのデフォルト値はTlsで、TLS 1.0プロトコルを示します。

.NETコネクタ・サーバーをアップグレードするには:

  1. コネクタ・サーバー・サービスを停止します。
  2. コネクタ・サーバーがインストールされているディレクトリのバックアップを作成します。
  3. 次のURLのOracle Technology Networkサイトからコネクタ・サーバー・パッケージ(Connector_Server_122130_dotnet.zip)をダウンロードします。
  4. コネクタ・サーバー・パッケージの内容を抽出し、ServiceInstall-version.msiファイルを探します。

    ノート:

    権限の少ないユーザーではすべてのコネクタ操作を実行できるわけではありません。そのため、.NETコネクタ・サーバーを実行するには、(最小限の権限があるユーザーとして)管理ユーザー・アカウントを使用する必要があります。

    12.2.1.3.0コネクタ・サーバー・パックに同梱されているServiceInstall- version.msiファイルを使用して、コネクタ・サーバーの既存の場所に12.2.1.3.0のバイナリをインストールします。つまり、C:\Program Files (x86)\Identity Connectors\Connector Serverディレクトリ、またはコネクタ・サーバーがインストールされている場所です。

  5. インストールした場所とバックアップの場所の両方でConnectorServer.exe.config ファイルを開きます。バックアップの場所のConnectorServer.exe.configファイルから、インストールした場所のConnectorServer.exe.configファイルの次のプロパティを更新します。
    <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"/> 
    <add key="logging.proxy" value="false"/>
    
  6. コマンド行で既存のキー値を使用して、新しくインストールしたコネクタ・サーバーのキーを設定します。

    .NETコネクタ・サーバーがインストールされているディレクトリに移動します。デフォルト・ディレクトリは次のとおりです。

    C:\Program Files (x86)\Identity Connectors\Connector Server

    次のコマンドを実行します。

    ConnectorServer.exe /setkey EXISTING_KEY

    このコマンドで、EXISTING_KEYはキーの値です。このキーは、クライアントがこの.NETコネクタ・サーバーに接続するときに必要になります。

  7. .NETコネクタ・サーバーの構成がすべて完了したら、Windowsサービスを再開するか、またはコマンド行インタフェースで次のコマンドを実行して.NETコネクタ・サーバーを再起動します。.NETコネクタ・サーバーがインストールされているディレクトリに移動し、次のコマンドを実行します。
    ConnectorServer.exe /run

    ノート:

    コネクタ・サーバーのアップグレード時には、手動アップグレードであるため、以前に行ったカスタマイズは保持されません。いずれかのファイルに他のカスタマイズがある場合は、バックアップの場所から同じことをもう一度行ってください。
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
4.6.3.6 .NETコネクタ・サーバーへの複数のコネクタのインストール

新しいアイデンティティ・コネクタをインストールするには、コネクタ・サーバーがインストールされているディレクトリに移動し、このディレクトリに新しいアイデンティティ・コネクタのZIPを解凍してから、コネクタ・サーバーを再起動します。