16-8 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
close any open FileReader or FileWriter instances. close connection with the target
close connection if any with database }
16.3.1.1.3 Implementing the getConfiguration Method
The getConfiguration method returns the Configuration instance passed to the Connector when the init method was used.
Example 16–13 illustrates how to
implement the getConfiguration method.
Example 16–13 getConfiguration Method Implementation
returns the Configuration of this connector Override
public Configuration getConfiguration { return this.flatFileConfig;
}
16.3.1.2 org.identityconnectors.framework.spi.Configuration
The implementation of this interface encapsulates the configuration of a connector. Configuration implementation includes all the necessary information of the target
system, which is used by the Connector implementation to connect to the target system and perform various reconciliation and provisioning operations. The
implementation should have a default Constructor with setters and getters defined for its properties. Every property declared may not be required but if a property is
required, then it should be marked required using the annotation org.identityconnectors.framework.spi.ConfigurationProperty. Configuration
implementation is a Java bean and all the instance variables mandatory or not do have default values. For example, a string userName is used to connect to the target
system and this is a mandatory attribute. This has a default value of null. When userName is a mandatory attribute, ICF expects a value to be provided by Oracle
Identity Manager. In other words, Oracle Identity Manager cannot miss out this parameter. If missed, then the connector throws ConfigurationException.
The implementation should check that all required properties are available and validated before passing itself to the Connector. The interface provides a validate
method for this purpose. For example, there are three mandatory configuration parameters, such as the IP address of the target, the username to connect to the target,
and the password for the user. The validate method implementation can check for non-NULL values and valid IP address by using regex.
Note: Sometimes, components must be able to access the
Configuration instance after initialization. This is supported by the accessor method getConfiguration.
Note:
ICF also provides a convenient base class org.identityconnectors.framework.spi.AbstractConfiguration for
configuration objects to extend.
Understanding the Identity Connector Framework 16-9
Example 16–14 Configuration Implementation
Configuration implementation for the flat file connector. public class FlatFileConfigurationImpl extends AbstractConfiguration{
The following sections contain information and sample code that illustrates how you might implement the Configuration methods.
The Configuration implementation must provide implementation for the following methods:
■
The validate Method
■
The setConnectorMessages Method
■
The getConnectorMessages Method
16.3.1.2.1 The validate Method
The validate method checks that the values of all required properties are set. It also validates that all values of configuration properties are valid. In other words, it
validates that all values of the configuration properties are in the expected range and have the expected format. If the configuration is not valid, then the implementations
generate the most specific RuntimeException available. When no specific exception is available, the implementations can throw ConfigurationException.
Example 16–15 illustrates how to implement the validate method.
Example 16–15 validate Method Implementation
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 ConfigurationExceptionUser store file not valid; FlatFileIOFactory.getInstancethis;
}
Here, if the target flat file provided is valid or not is checked, such as is a file, is writeable, is readable. If not valid, then an exception is generated.
Implementations of the validate method should NOT connect to the target system to validate the properties.
16.3.1.2.2 The setConnectorMessages Method
The setConnectorMessages method sets the org.identityconnectors.framework.common.objects.ConnectorMessages message
catalog instance, allowing the Connector to localize messages. Example 16–16
illustrates the setConnectorMessages method definition.
Note: This implementation depends on an instance variable private
File storeFile and a supporting class FlatFileIOFactory. A complete implementation is illustrated in
Developing a Flat File Connector on
page 17-1.
16-10 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
Example 16–16 setConnectorMessages Method Definition
public final void setConnectorMessagesConnectorMessages messages { _connectorMessages = messages;
}
16.3.1.2.3 The getConnectorMessages Method
The getConnectorMessages method returns the ConnectorMessages set by the setConnectorMessages method.
Example 16–17 illustrates the getConnectorMessages
method definition.
Example 16–17 getConnectorMessages Method Definition
public final ConnectorMessages getConnectorMessages { return _connectorMessages;
}
16.3.2 Implementing the Feature-based Interfaces
The following sections contain information on the interfaces used to enable identity connector pooling and attribute normalizing.
■
org.identityconnectors.framework.spi.PoolableConnector
■
org.identityconnectors.framework.spi.AttributeNormalizer
16.3.2.1 org.identityconnectors.framework.spi.PoolableConnector
Connection pooling by ICF is a feature provided by the ICF in which the framework maintains a pool of connector instances and uses them while performing provisioning
and reconciliation operations. Connectors can make use of pooling by implementing the PoolableConnector interface instead of plain Connector interface. To make use of
this feature, implement the PoolableConnector interface. If you implement the Connector interface, then ICF creates a new connector instance for every operation,
creates a new connection with the target, completes the provisioningreconciliation operation, removes the connection with the target system, and finally disposes this
connector instance. Therefore, the advantages of implementing PoolableConnector is that a pool of configurable connector instances are maintained and are reused for
many operations.
Some of configurable options are:
■
Maximum connector objects in the pool that are idle and active _maxObjects
■
Maximum connector objects that are idle _maxIdle
■
Max time to wait if the pool is waiting for a free object to become available before failing _maxWait
■
Minimum time to wait before evicting an idle object _minEvictableIdleTimeMillis
■
Minimum number of idle objects _minIdle These values must be set by connector API developer, and if not provided, then the
following default values are used:
■
_maxObjects = 10
■
_maxIdle = 10
Understanding the Identity Connector Framework 16-11
■
_maxWait = 150 1000 ms
■
_minEvictableIdleTimeMillis = 120 1000 ms
■
_minIdle = 1 The PoolableConnector interface extends the Connector interface. It is implemented to
enable identity connector pooling that ICF provides. ICF must make sure that the Connector instance is alive before being used. For this purpose, the interface provides
a checkAlive method. Example 16–18
is a sample flat file PoolableConnector implementation.
Example 16–18 Flat File Poolable Connector Implementation
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,SearchOpMapString, String,UpdateOp{
To implement the PoolableConnector interface, provide an implementation of the checkAlive method along with all the methods discussed in
Section 16.3.1.1, org.identityconnectors.framework.spi.Connector.
The checkAlive method determines if the Connector instance is alive and can be used for operations on the
target system. checkAlive can be called often thus the developer should make sure the implementation is fast. The method should throw a specific RuntimeException if
available when the Connector is no longer alive. Example 16–19
illustrates how to implement the checkAlive method.
Example 16–19 checkAlive Method Implementation
Checks if this connector is alive, if not throws a RuntimeException Override
public void checkAlive { check if the connector is still connected to target
}
16.3.2.2 org.identityconnectors.framework.spi.AttributeNormalizer
This interface must be implemented by a Connector that needs to normalize any attributes passed to it. A normalizer converts values to a standard form for the
purpose of display, consumption, or comparison. For example, a normalizer might convert text values to a specific case, trim whitespace, or order the elements of a DN in
a specific way.
The interface defines a normalizeAttribute method for this purpose. This method takes an ObjectClass and an Attribute to be normalized as arguments and returns the
normalized Attribute. Attribute normalization is applied during many operations including:
■
Filters that are passed to SearchOp
■
Results returned from SearchOp
16-12 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
■
Results returned from SyncOp
■
Attributes passed to UpdateAttributeValuesOp
■
Uids returned from UpdateAttributeValuesOp
■
Attributes passed to UpdateOp
■
Uids returned from UpdateOp
■
Attributes passed to CreateOp
■
Uids returned from CreateOp
■
Uids passed to DeleteOp Example 16–20
illustrates the normalizeAttribute method definition.
Example 16–20 normalizeAttribute Method Defintion
public Attribute normalizeAttribute ObjectClass oClass, Attribute attribute { if attribute instanceof Uid {
return new UidLdapUtil.createUniformUidStringnewValues.get0, configuration.getSuffix;
} }
16.3.3 Implementing the Operation Interfaces
Each operation interface defines an action that the Connector may perform on a target system, if supported by it. The operation interfaces belong to the
org.identityconnectors.framework.spi.operations package. The names of these operation interfaces are listed below, but subsequent sections elaborate on each
interface:
■
AuthenticateOp
■
CreateOp
■
DeleteOp
■
ResolveUsernameOp
■
SchemaOp
■
ScriptOnConnectorOp
■
ScriptOnResourceOp
■
SearchOpTSyncOp
■
TestOp
■
UpdateAttributeValuesOp
■
UpdateOp The following sections contain more information on some of these operations.
■
Implementing the SchemaOp Interface
■
Implementing the CreateOp Interface
■
Implementing the DeleteOp Interface
■
Implementing the SearchOp Interface
■
Implementing the UpdateOp Interface
Understanding the Identity Connector Framework 16-13
16.3.3.1 Implementing the SchemaOp Interface
The SchemaOp interface is implemented to allow the connector to describe the objects it can handle on the target system. The schema that a connector returns describes the
object-classes that it exposes for management. Each object-class has a name, a description, and a set of attribute definitions. Each attribute definition has a name, a
syntax, and certain flags that describe its properties, such as multi-valued, single-valued, readable, or writeable.
The schema that a connector returns describes the attributes of each type of object that the connector exposes. Sometimes, this requires translation from an internal
representation to this Schema format. In other instances, the Schema presents as an attribute; something that is natively available only via calls to the target API.
Irrespective of how the SPI implementation accomplishes the mapping between the native representation and the corresponding ConnectorObject, the Schema provides
the metadata that describes what a client can expect to find in a ConnectorObject of each type, which is objectClass.
To implement this interface, provide an implementation for the schema method as defined in
Example 16–21 .
Example 16–21 schema Method Signature
public Schema schema The implementation should return the schema containing the types of objects that this
identity connector supports.
Example 16–22 schema Method Implementation
Override public Schema schema {
SchemaBuilder flatFileSchemaBldr = new SchemaBuilderthis.getClass; SetAttributeInfo attrInfos = new HashSetAttributeInfo;
for String fieldName : flatFileMetadata.getOrderedTextFieldNames { AttributeInfoBuilder attrBuilder = new AttributeInfoBuilder;
attrBuilder.setNamefieldName; attrBuilder.setCreateabletrue;
attrBuilder.setUpdateabletrue; attrInfos.addattrBuilder.build;
} Supported class and attributes
flatFileSchemaBldr.defineObjectClass ObjectClass.ACCOUNT.getDisplayNameKey, attrInfos;
return flatFileSchemaBldr.build; }
16.3.3.2 Implementing the CreateOp Interface
The CreateOp interface is implemented to enable creating objects on the target system. To implement this interface, provide an implementation of the create method, as
shown in Example 16–23
.
Note: The Uid should not appear in the returned schema.
16-14 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
Example 16–23 create Method Signature
public Uid create ObjectClass objectClass, SetAttribute attributes,
OperationOptions options
This method takes an ObjectClass for example, account or group, a set object attributes, and operation options. The implementation creates an object on the target
system by using passed object attributes and object type defined by ObjectClass. The ObjectClass argument specifies the class of object to create. The class of object to be
created is one of the inputs to the create operation. ObjectClass is the first argument to the create method, as shown in
Example 16–24 .
Example 16–24 create Method Implementation
Override public Uid createObjectClass arg0, SetAttribute attrs,
OperationOptions ops { System.out.printlnCreating user account + attrs;
assertUserObjectClassarg0; try {
FlatFileUserAccount accountRecord = new FlatFileUserAccountattrs; Assert uid is there
assertUidPresenceaccountRecord; Create the user
this.flatFileWriter.addAccountaccountRecord; Return uid
String uniqueAttrField = this.flatFileConfig .getUniqueAttributeName;
String uniqueAttrVal = accountRecord .getAttributeValueuniqueAttrField;
System.out.printlnUser + uniqueAttrVal + created; return new UiduniqueAttrVal;
} catch Exception ex { If account exists
if ex.getMessage.containsexists throw new AlreadyExistsExceptionex;
For all other causes System.out.printlnError in create + ex.getMessage;
throw ConnectorException.wrapex; }
}
If the operation is successful, Uid instance representing object identifier on the target system is supposed to be created and returned. The caller can then use the Uid to refer
to the created object.
16.3.3.3 Implementing the DeleteOp Interface
The DeleteOp interface is implemented to enable deleting objects from the target system. To implement this interface, provide an implementation for the delete method
as defined in Example 16–25
.
Understanding the Identity Connector Framework 16-15
Example 16–25 delete Method Signature
public void delete ObjectClass objectClass, Uid uid, OperationOptions options
This method takes an ObjectClass for example, account or group, the Uid of the object being deleted from the target system, and operation options. The
implementation deletes the object identified by the provided Uid from the target system. if the object does not exist on the target system, then an
org.identityconnectors.framework.common.exceptions.UnknownUidException is generated.
Example 16–26 illustrates how to implement the delete method.
Example 16–26 delete Method Implementation
Override public void deleteObjectClass arg0, Uid arg1, OperationOptions arg2 {
final String uidVal = arg1.getUidValue; this.flatFileWriter.deleteAccountuidVal;
log.okAccount {0} deleted, uidVal; }
16.3.3.4 Implementing the SearchOp Interface
The SearchOp interface is implemented to enable searching objects on the target system. Here, the search operation consists of:
■
Creation of a native filter to implement search conditions that are specified generically.
■
Executing the actual query. Implementing these methods in the SPI allows the API to support search. The API
performs by post-processing the result any filtering that the connector does not perform, for example, by translating any specified filter conditions into native search
conditions.
To implement this interface, provide an implementation for the createFilterTranslator and executeQuery methods as documented in the following sections.
■
Implementing the createFilterTranslator Method
■
Implementing the executeQuery Method
16.3.3.4.1 Implementing the createFilterTranslator Method
The createFilterTranslator method returns an instance of implementation of FilterTranslator, which converts the ICF Filter object passed to it from the API side into
a native query. Following the conversion, ICF passes the query to the executeQuery method.
Example 16–27 illustrates the createFilterTranslator method definition.
Example 16–27 createFilterTranslator Method Signature
public FilterTranslator createFilterTranslator ObjectClass oClass, OperationsOptions options
Note: If the delete operation fails, then ICF generates subclasses of
RuntimeException. See Oracle Fusion Middleware Java API Reference for Identity Connector Framework for details.
16-16 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
Example 16–28 illustrates an implementation of the createFilterTranslator method.
Example 16–28 createFilterTranslator Method Implementation
Override public FilterTranslatorMapString, String createFilterTranslator
ObjectClass arg0, OperationOptions arg1 { return new ContainsAllValuesImpl {
}; }
This example supports only a single type of search predicate, which is ContainsAllValues. See
Implementation of AbstractFilterTranslatorT on page 17-8
for an example of an implementation of ContainsAllValuesImpl. The implementation of ContainsAllValues translates into native form a condition of the form: Attribute A
contains all of the values V1, V2 ... VN.
For information on the org.identityconnectors.framework.common.objects.filter.FilterTranslator, see
Common Classes on page 16-18.
16.3.3.4.2 Implementing the executeQuery Method
The executeQuery method is called for every query produced by the FilterTranslator implementation as documented in
Implementing the createFilterTranslator Method on page 16-15. It takes an ObjectClass for example, account or group, the query, an
instance of ResultsHandler used as a callback to handle found objects, and operation options, as illustrated in
Example 16–29 .
Example 16–29 executeQuery Method Signature
public void executeQuery ObjectClass oClass, T query,
ResultsHandler handler, OperationOptions options
The implementation of the executeQuery method searches for the target objects by using the passed query, creates instances of ConnectorObject for each target object
found, and uses ResultsHandler to handle ConnectorObjects. ConnectorObject is ICF representation of target resource object. It contains information such as ObjectClass,
Uid, Name, and Set of Attributes. ConnectorObject is central to search. executeQuery streams ConnectorObjects into the ResultsHandler, and therefore, to the client.
Example 16–30 illustrates how to implement the exectueQuery method.
Example 16–30 executeQuery Method Implementation
Override public void executeQueryObjectClass objectClass,
MapString, String matchSet, ResultsHandler resultHandler, OperationOptions ops {
searches the flat file for accounts which fulfil the condition matchSet created by FilterTranslator
IteratorFlatFileUserAccount userAccountIterator = this.flatFileParser .getAccountIteratormatchSet;
Note: The return value should not be null.
Understanding the Identity Connector Framework 16-17
boolean handleMore = true; while userAccountIterator.hasNext handleMore {
FlatFileUserAccount userAcc = userAccountIterator.next; ConnectorObject userAccObject = convertToConnectorObjectuserAcc;
Let the client handle the result by doing callback handleMore = resultHandler.handleuserAccObject;
} while userAccountIterator.hasNext {
FlatFileUserAccount userAcc = userAccountIterator.next; ConnectorObject userAccObject = convertToConnectorObjectuserAcc;
if resultHandler.handleuserAccObject { System.out.printlnNot able to handle + userAcc;
break; }
} }
16.3.3.5 Implementing the UpdateOp Interface
The UpdateOp interface is implemented to enable updating objects on the target system. To implement this interface, provide an implementation of the update method
as defined in Example 16–31
.
Example 16–31 update Method Signature
public Uid updateObjectClass oClass, Uid uid, SetAttribute attributes, OperationOptions options
This method takes an ObjectClass for example, account or group, Uid of the object being updated, a set of object attributes being updated, and operation options. The
implementation updates the object on the target system identified by the Uid with the new values of attributes. If the object identified by the Uid does not exist on the target
system, then an UnknowUidException is generated.
Example 16–32 illustrates how to
implement the update method.
Example 16–32 update Method Implementation
Override public Uid updateObjectClass arg0, Uid arg1,
SetAttribute arg2, OperationOptions arg3 { String accountIdentifier = arg1.getUidValue;
Fetch the account FlatFileUserAccount accountToBeUpdated = this.flatFileParser
.getAccountaccountIdentifier; Update
accountToBeUpdated.updateAttributesarg2; this.flatFileWriter
.modifyAccountaccountIdentifier, accountToBeUpdated; log.okAccount {0} updated, accountIdentifier;
Return new uid String newAccountIdentifier = accountToBeUpdated
.getAttributeValue this.flatFileConfig.getUniqueAttributeName;
return new UidnewAccountIdentifier; }
16-18 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
16.3.4 Common Classes
There are many ICF classes mentioned in the previous sections. The most important classes are:
■
org.identityconnectors.framework.common.objects.Attribute An Attribute is a named collection of values within a target system object. A target
system object may have many attributes and each may have many values. In its simplest form, an Attribute can be considered a name-value pair of a target system
object. Empty and null values are supported. The developer should use org.identityconnectors.framework.common.objects.AttributeBuilder to construct
Attribute instances.
■
org.identityconnectors.framework.common.objects.Uid A single-valued Attribute Uid is a subclass of Attribute that represents the
unique identifier of an object on the target resource. Ideally, it should be immutable.
■
org.identityconnectors.framework.common.objects.ObjectClass An ObjectClass defines the type of the object on the target system. Account, group,
or organization are examples of such types. ICF defines predefined ObjectClasses for account ObjectClass.ACCOUNT and group ObjectClass.GROUP.
■
org.identityconnectors.framework.common.objects.ConnectorObject A ConnectorObject represents an object for example, an account or group on the
target system. The developer must use org.identityconnectors.framework.common.objects.ConnectorObjectBuilder to
construct a ConnectorObject.
■
org.identityconnectors.common.security.GuardedString A guarded string is a secure String implementation which solves the problem of
storing passwords in memory in a plain String format. Passwords are stored as Bytes in an encrypted format. The encryption key will be randomly generated.
■
org.identityconnectors.framework.common.objects.filter.FilterTranslator A FilterTranslater object is responsible for converting all the filters specified on the
API side of the ICF into native queries during a search operation. ICF Filters support both search predicates and logical operators:
–
Search predicates match objects based on the values of a specified attribute. For example, an EqualsFilter returns true when at least one value of an
attribute is equal to a specified value.
–
Logical operators AND and OR join search predicates to build complex expressions. For example, an expression of the form A AND B is true only if
both A and B are true. An expression of the form A OR B is true if at least one of A or B is true.
Note: All attributes are syntactically multivalued in this model. A
particular attribute being singlevalued is only a semantic restriction.
Note:
A singlevalued attribute is particularly relevant to UID being a unique identifier.
Understanding the Identity Connector Framework 16-19
The ICF provides the AbstractFilterTranslatorT base class to make search implementation easier. A FilterTranslator sub class should override the following
whenever possible.
– createAndExpressionT, T
– createOrExpressionT, T
– createContainsExpressionContainsFilter, boolean
– createEndsWithExpressionEndsWithFilter, boolean
– createEqualsExpressionEqualsFilter, boolean
– createGreaterThanExpressionGreaterThanFilter, boolean
– createGreaterThanOrEqualExpressionGreaterThanOrEqualFilter, boolean
– createStartsWithExpressionStartsWithFilter, boolean
– createContainsAllValuesExpressionContainsAllValuesFilter, boolean
For more information see Section 16.3.3.4, Implementing the SearchOp Interface.
■
org.identityconnectors.framework.common.objects.ResultsHandler This is a callback interface for operations returning one or more results. The sub
class should provide an implementation to the handle method whereas the caller can decide what to do with the results. Currently, this is used only by the
SearchOp interface. For more information, see Section 16.3.3.4, Implementing the
SearchOp Interface.
16.4 Extending an Identity Connector Bundle
An identity connector bundle is the specific implementation for a particular target system. The bundle is a Java archive JAR that contains all the files required by the
identity connector to connect to the target system and perform operations. It also has special attributes defined in the MANIFEST file that are recognized by the ICF. These
are:
■
ConnectorBundle-FrameworkVersion is the minimum version of the ICF
required for this identity connector bundle to work. Newer ICF versions will be backwards compatible.
■
ConnectorBundle-Name is the unique name for this identity connector bundle; it
is generally the package name.
■
ConnectorBundle-Version is the version of this bundle. Within a given
deployment of Oracle Identity Manager, the ConnectorBundle-Name and ConnectorBundle-Version combination should be unique.
You extend an identity connector bundle, for example, to reuse common code. The AbtractDatabaseConnector is a good example, because different types of connectors
can reuse the same basic logic that accesses database tables using JDBC. A connector for database tables might share this common code with a connector for Oracle
Database users, a connector for IBM DB2 database users, and a connector for MySQL users.
A given Connector can be extended by adding the extended bundle to the lib directory of a new bundle and creating a new class that subclasses the target class.
This can be illustrated with the AbstractDatabaseConnector bundle. The common logic would be in a common bundle as follows:
16-20 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
■
META-INFMANIFEST.MF –
ConnectorBundle-FrameworkVersion: 1.0
– ConnectorBundle-Name: org.identityconnectors.database.common
– ConnectorBundle-Version: 1.0
■
org.identityconnectorsdatabasecommonAbstractDatabaseConnector.class
■
orgidentityconnectorsdatabasecommon other common source files
■
lib There would be as many database resource specific bundles as needed. For example:
■
META-INFMANIFEST.MF –
ConnectorBundle-FrameworkVersion: 1.0
– ConnectorBundle-Name: org.identityconnectors.database.mysql
– ConnectorBundle-Version: 1.0
■
orgidentityconnectorsdatabasemysqlMySQLConnector.class subclass of AbstractDatabaseConnector
■
orgidentityconnectorsdatabasemysql other MySQL source files
■
liborg.identityconnectors.database.common-1.0.jar parent bundle described above
■
lib specific database drivers and libraries as needed
16.5 Using an Identity Connector Server
An identity connector server is required when an identity connector bundle is not directly executed within your application. By using one or more identity connector
servers, the ICF architecture permits your application to communicate with externally deployed identity connector bundles. Identity connector servers are available for
Java™ and Microsoft .NET Framework applications.
A single connector server can support multiple ICF connectors, and these ICF connectors may be of different connector types. A single ICF connector can be used to
communicate with multiple targets.
Figure 16–3 shows how Oracle Identity Manager connectors integrate with resources
via ICF connectors:
Note: You do not extend the original bundle. Instead, you extend the
connector by embedding the original bundle in a new bundle that wraps the original bundle.
Note: This identity connector would not have a ConnectorClass
annotation.
Note: This identity connector would have a ConnectorClass
annotation.
Understanding the Identity Connector Framework 16-21
Figure 16–3 ICF Connectors and Connector Server
In Figure 16–3
:
■
Oracle Identity Manager connectors do not directly interact with the target resource. Instead, the create, read, update, delete, and query CRUDQ operations
are performed via the appropriate ICF connector.
■
A single ICF Connector can be used to connect to multiple resources of the same resource type. In
Figure 16–3 , an ICF Connector for LDAP is used to connect to a
local LDAP resource, as well as being used to connect to a remote LDAP resource.
■
The .NET Connector Server is used to deploy .NET ICF Connectors on the target host. An Active Directory resource is connected in this manner.
■
An ICF Connector for Google Apps provides a connection to Google Apps across the Internet.
■
While not shown in the diagram, a Connector Server can support multiple ICF Connectors of different resource types.
The types of connector servers are described in the following sections:
■
Using the Java Connector Server
■
Using the Microsoft .NET Framework Connector Server
16-22 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager
16.5.1 Using the Java Connector Server
A Java Connector Server is used when you do not want to execute a Java Connector Bundle in the same Java Virtual Machine JVM as the application. This deployment
may be beneficial in terms of performance as the bundle works faster when deployed on the same host as the managed target system. In addition, use Java Connector Server
to eliminate possibility of an application JVM crash because of faulty JNI-based connector.
Using the Java connector server is described in the following sections:
■
Installing and Configuring a Java Connector Server
■
Running the Java Connector Server on Microsoft Windows
■
Running the Java Connector Server on Solaris and Linux
■
Installing an Identity Connector in a Java Connector Server
■
Using SSL to Communicate with a Connector Server
16.5.1.1 Installing and Configuring a Java Connector Server
To install and configure the Java Connector Server:
1.
Create a new directory on the computer on which you want to install the Java Connector Server. In this section, CONNECTOR_SERVER_HOME represents this
directory.
2.
Unzip the Java Connector Server package in your new directory from Step 1. Java Connector Server is available for download in the Oracle Technology Network
Web site at the following URL:
http:www.oracle.comtechnetworkindex.html
3.
In the ConnectorServer.properties file in the conf directory, set the properties as required by your deployment.
Table 16–1 lists the properties in the
ConnectorServer.properties file:
Tip: Get the following information defined during installation for
use during either Connector Server configuration.
■
Host name and IP address
■
Connector Server port
■
Connector Server key
■
SSL enabled
Table 16–1 Properties in the ConnectorServer.properties File
Property Description
connectorserver.port Port on which the Java Connector Server listens for requests. The
default value is 8759. connectorserver.bundleDir
Directory where the connector bundles are deployed. The default value is bundles.
connectorserver.libDir Directory in which to place dependent libraries. The default
value is lib.
