Programming Guides › Connector Programming Guide › Implementing Connectors › Connector Base Classes

Connector Base Classes

Decide which type of connector you want to implement. The CA IAM CS SDK provides several abstract connector base classes you can extend:

• com.ca.jcs.BaseConnector—Implement this class to implement all connector behavior in the Java code of the connector itself.

  Note: Extending MetaConnector is a much faster and less error-prone alternative because flexible metadata rather than static Java code drives most of the logic.

• com.ca.jcs.meta.MetaConnector—A connector translates LDAP concepts such as DNs to identifiers on the endpoint system, and to map LDAP attribute name to native object concepts. MetaConnector and all its subclasses perform this job, and also take care of basic attribute validation and conversion tasks as outlined in the data model metadata stored on their parent endpoint type. This class is the basis for all metadata-driven connectors.

  Most endpoint systems have a flat (nonhierarchical) structure, which is reflected by extending from MetaConnector and overriding its isBehaviourSearchSingleClass() method to return true. This causes the framework to call your connectors’ attribute-style processor’s doSearch() method with one object class at a time (even when a SEARCH filter matches multiple object classes), greatly simplifying the implementation of this method.

  However, for performance and logical grouping reasons, it is best to present objects of the same type (accounts/groups) as contained in their own virtual container. This class takes care of presenting these logical virtual containers on your behalf where virtual containers are specified in the connector's conf/connector.xml configuration file.

  Note: For more information, see the SDK example connector.

  Note: Defining virtual containers more dynamically in metadata is considered best practice. For an example, see the definition of the eTDYNAccountContainer class in cs-sdk-home/connectors/sdkdyn/conf/sdkdyn_metadata.xml). Most custom connectors can be implemented by extending this class.

  If your custom connector supports a hierarchy (such as an LDAP or JNDI directory), and you want to represent this information in your connector, this class (or one of its derived classes) we recommended that you start with this class. If the endpoint system search semantics map clearly to LDAP search filters that can match multiple objectclasses, then write your connector so that it does not define isBehaviourSearchSingleClass(), as it defaults to false.

  Other Boolean behavioral methods include:

  • isBehaviourSearchObjAsLookup()—Should a SEARCH on a single object be turned into a doLookUp() call to simplify the implementation of your connector’s attribute-style processor’s doSearch() method?

    When the connector returns true from isBehaviourSearchObjAsLookup() in its metaConnector class, the CA IAM CS calls the connectors doLookup() method when a base level search request is received. When there is a search filter included in the search request, it is ignored by CA IAM CS. As a result, CA IAM CS sometimes returns search results that should not be returned according to the search filter used in the original search request.

    Some connectors can utilize BehaviourSearchObjAsLookup() method, by overriding it to return true to mean that they want to take advantage of CA IAM CS changing some searches into lookups (where applicable).

    When this happens, CA IAM CS now post filters the lookup result to ensure it complies with the original search filter (if any).

  • isObjectClassRequired()—-Should the objectclass be passed through in the attributes passed to your connector (by default this is set to !isBehaviourSearchSingleClass()).
  • isHiddenLdapBaseDn()—Should the base DN be hidden for a hierarchical connector?
  • isBehaviourStrictConnectorDns()—Should connector-speak DNs be handled as strictly RFC 2253 conformant? Defaults to false.
  • isIndirectAssociations()—Does your connector strictly represent associations between objects by using a

    table

    external to both of the objects? The default value returned by this method is null, which means that metadata will be consulted it order to determine the style of association for each association (for instance the JDBC connector supports both indirect and direct styles of associations). Where the style of associations is strictly defined by the technology of the endpoint system either true or false should be returned as appropriate. For instance the JNDI connector returns "false" from this method as LDAP technology does not support indirect associations.
  • isHiddenLdapBaseDn()—Should the base DN be hidden for a hierarchical connector?
  • isAutoDirectAssocRequired()—If your connector makes of direct associations, then returning true from this method causes the CA IAM CS framework to use the com.ca.jcs.assoc.AssocAttributeOpProcessorProxy class to implement virtual reverse association. attributes for your connector.

Note: For more information, see the SDK example and the CA IAM CS Javadoc in the CA IdentityMinder bookshelf.