Writing Custom Adapters

After finishing the preparation work described in Preparing for Adapter Development you are ready to start writing your custom adapter.

This section describes how to write a custom adapter, including:

• Process Overview

• Rename the Skeleton File

• Edit the Source File

• Map the Attributes

• Specify the Identity Template

• Write the Adapter Methods

• Configure the Adapter to Support Pass-Through Authentication

• Define the Resource Object Components

Process Overview

The following sections provide a high-level overview of the steps you perform to create a custom adapter:

• How To Write a Standard Resource Adapter

• How To Write an Active Sync-Enabled Resource Adapter

How To Write a Standard Resource Adapter

This section describes the processes to follow when creating a standard adapter or an Active Sync-enabled adapter.

The steps for writing a standard adapter are slightly different based on which operating system you are using.

To Create a Standard Adapter:

1. Open a command window and go to the following directory:

   \waveset\idm\adapter\src

2. Rename the SkeletonStandardResourceAdapter.java skeleton file to a file name of your choice. See Rename the Skeleton File for more information.

3. Edit the new adapter’s source file as described in Edit the Source File.

4. Source the file you created previously to set up your environment:

   • For Windows: Source the ws.bat file.

   • For UNIX: Source the ws.sh file.

5. Type the following command to compile your source files:

   • For Windows: javac -d . -classpath %CLASSPATH% yourfile.java

   • For UNIX: javac -d . -classpath $CLASSPATH yourfile.java

How To Write an Active Sync-Enabled Resource Adapter

This section describes the general steps you follow to create a custom Active Sync-Enabled adapter on the Microsoft Windows operating system.

To Create a Custom Active Sync-Enabled Adapter

1. Open a command window and change to the following directory:

   \waveset\idm\adapter\src

2. Rename (or copy) one of the following skeleton files to a file name of your choice. See Rename the Skeleton File for more information.

   • SkeletonStandardAndActiveSyncResourceAdapter.java (for standard and Active Sync-enabled resources)

   • SkeletonActiveSyncResourceAdapter.java (for Active Sync-only resources)

3. Edit the new adapter’s source file as described in Edit the Source File.

4. Source the file you created previously to set up your environment:

   • For Windows: Source the ws.bat file.

   • For UNIX: Source the ws.sh file.

5. Type the following command to compile your source files:

   • For Windows: javac -d . -classpath %CLASSPATH% yourfile.java

   • For UNIX: javac -d . -classpath $CLASSPATH yourfile.java

Rename the Skeleton File

You must rename the skeleton adapter to a name that is appropriate for your new adapter. Perform the following actions:

• Rename the sample java file to match your new class name.

• Edit the source code to replace the sample class name with the new class name.

Edit the Source File

After renaming the skeleton file, you must edit the new adapter’s source code to replace specific text strings and to define default values you want the adapter to support.

To Edit the Source File

1. Search for, and replace, the following text strings to determine where you must make adapter-specific modifications in the code.

   • change-value-here strings indicate where you must enter a substitution.

   • @todo strings indicates where you must rewrite a method for a particular scenario you are supporting.

2. Name the resource adapter type.

   This name displays in the New Resources menu in the Identity Manager Administrator interface.

3. Map the incoming resource attributes to Identity Manager account attributes by replacing default values in the prototypeXML string with your own default values for this adapter type. For example, you might want to delete the RA_GROUPS attribute from your adapter type.

   See Map the Attributes for more information.

4. Add or delete methods from the skeleton file. In particular, you must add Java code to support join, leave, and move operations, which are not supported in this example file.

   See Write the Adapter Methods for more information.

5. After editing the adapter file, you can load it into Identity Manager.

Map the Attributes

Generally, you set options for the adapter type by mapping the incoming resource attributes to the standard Identity Manager account attributes or by creating your own custom attributes (called extended schema attributes).

Your resource must define resource attributes and set default values for resource attributes for which it makes sense to have default. The resource does not have to present the prototypeXML object.

The attributes in SkeletonActiveSyncResourceAdapter are mandatory. Do not delete these attribute definitions when customizing the file.

Mapping Resource Attributes to Standard Account Attributes

To map incoming resource attributes to one of the standard Identity Manager account attributes, use the syntax shown in the following example.

Example 9–3 Mapping a Resource Attribute

"<AccountAttributeTypes>\n"+ <AccountAttributeType name=’accountId’ mapName=’change-value-here’
mapType=’string’ required=’true’>\n"+ "<AttributeDefinitionRef>\nt"+  <ObjectRef type=’AttributeDefinition’
name=’accountId’/>\n"+ "</AttributeDefinitionRef>\n"+ "</AccountAttributeType>\n"+
 "</AccountAttributeTypes>\n"+

Where:

• The <AccountAttributesTypes> element surrounds the prototypeXML string where you map the resource attribute to the Identity Manager account attribute.

• The <AttributeDefinitionRef> element identifies the Identity Manager account attribute.

  The following table describes the <AttributeDefinitionRef> element fields.

For more information on mapping resource attributes to account attributes, see Map the Attributes.

Mapping Resource Attributes to Extended Schema Attributes

To map incoming resource attributes to attributes other than a standard Identity Manager attribute, you must create an extended schema attribute. The following example illustrates how to map a resource attribute to an extended schema attribute.

Example 9–4 Mapping a Resource Attribute to an Extended Schema Attribute

<AccountAttributeType name=’HomeDirectory’ type=’string’ mapName=’HomeDirectory’
mapType=’string’>\n"+ </AccountAttributeType>\n"+

You do not have to declare an ObjectRef type. The mapName field identifies the custom account attribute HomeDirectory. You define the mapType field the same as you would when mapping an attribute to a standard account attribute.

Specify the Identity Template

You must use an identity template (or an account DN) to uniquely identify every user and group in your enterprise.

DNs display on the following Identity Manager User interface pages:

• Resources

• Distinguished Name Template

• Edit Schema

For more information about identity templates, see Identity Template.

Write the Adapter Methods

The Identity Manager adapter interface provides general methods that you must customize to suit your particular environment. This section briefly describes:

• How to Write Standard Resource Adapter-Specific Methods

• How to Write Active Sync-Enabled Adapter Methods

How to Write Standard Resource Adapter-Specific Methods

Standard resource adapter-specific methods are specific to the resource you are updating to synchronize with Identity Manager.

The body of a resource adapter consists of resource-specific methods. Consequently, the resource adapter provides methods that are only generic placeholders for the specific methods that you will write.

This section describes how the methods used to implement operations are categorized. The information is organized into the following sections:

• Creating the Prototype Resource

• Connecting with the Resource

• Checking Connections and Operations

• Defining Features

• Disabling User Accounts

• Enabling Pass-Through Authentication for Resource Types

When writing a custom adapter

• Call the setdisabled() method on any WSUser object that is returned by a custom method.

• If the adapter implements the AsynchronousResourceAdapter class, then note that this adapter might be working with users that are partially initialized. (These users are created outside Identity Manager, but not fully populated with attributes.) The Provisioner does not automatically convert a Create operation to an Update operation if the WSUser already exists on the resource. Your resource adapter must distinguish this case.

Creating the Prototype Resource

The following table describes the methods used to create a Resource instance.

Connecting with the Resource

The following methods are responsible for establishing connections and disconnections as an authorized user. All resource adapters must implement these methods.

• startConnection

• stopConnection

Checking Connections and Operations

ResourceAdapterBase provides methods that you can use to check the validity of an operation, such as whether the connection to the resource is working, before the adapter attempts the actual operation.

The following table describes methods you can use to verify that your adapter is communicating with the resource and that the authorized account has access.

Defining Features

The getFeatures() method specifies which features are supported by an adapter. The features can be categorized as follows:

• General features

• Account features

• Group features

• Organizational unit features

The ResourceAdapterBase class defines a base implementation of the getFeatures() method. The Enabled in Base? column in the following tables indicates whether the feature is defined as enabled in the base implementation in ResourceAdapterBase.

If your custom adapter overrides the ResourceAdapterBase implementation of the getFeatures method, add code similar to the following:

public GenericObject getFeatures() {
GenericObject genObj = super.getFeatures();
genObj.put(Features.ACCOUNT_RENAME, Features.ACCOUNT_RENAME);
genObj.remove(Features.ACCOUNT_UPDATE, Features.ACCOUNT_UPDATE);
.. other features supported by this Resource Adapter …
return genObj;
}

To disable a feature by overriding a different method (such as supportsActions) add code similar to the following:

public boolean supportsActions() {
   return true;
}

The following tables describe the methods used to create, delete, and update accounts on Resources.

You can use list methods to establish processes that adapters use to retrieve user information from the resource.

Best Practice

When writing an AccountIterator interface implementation for a custom adapter, try to do the following:

• Have the AccountIterator.next() method return a user that contains all attributes in the schema map when getAccountIterator() is called. The reconciler will trim the schema (in a cloned resource used for the getAccountIterator() request) to request only those attributes the reconciler needs. Generally, the reconciler needs only the accountId attribute; but there are cases when the reconciler has additional attributes in the schema. Other getAccountIterator() users, such as Load From Resource, potentially need all of the schema attributes.

  Try to create a “smart” adapter that does the right thing based on what is in the schema map. If your adapter can just list the accounts and get the requested information, then the adapter should just do those tasks. Otherwise, the adapter might have to fetch an account to get the required attributes. Adapters that are not smart always get all the attributes.

• Make your adapter as scalable as possible, which generally means the adapter does not list or fetch all of the accounts at once. Instead, your adapter should iterate over the accounts as the AccountIterator.next() method is called. Avoid having your adapter do much in the AccountIterator constructor.

The following example shows code for retrieving information from a resource and converting that information into information that Identity Manager can work with.

Resource Adapters: Retrieving Information on a Resource

public WSUser getUser(WSUser user)
 throws WavesetException {
    String identity = getIdentity(user);
     WSUser newUser = null;
    try {
         startConnection();
        Map attributes = fetchUser(user);
         if (attributes != null) {
             newUser = makeWavesetUser(attributes);
         }
     } finally {
         stopConnection();
     }
     return newUser;
 }

Disabling User Accounts

You can disable an account by using the disable utilities supported by the resource or the account disable utility provided by Identity Manager.

Use native disable utilities whenever possible.

• Native support for disabling an account: Certain resources provide a separate flag that, when set, prevents users from logging in. Example utilities include User Manager for Active Directory Users and Computers for Active Directory, and ConsoleOne or Netware Administrator for NDS/Netware. When an account is enabled, the user’s original password is still valid. You can determine whether native support for account disable is available on your resource by implementing the supportsAccountDisable method.

• Identity Manager disable utility: If the resource does not support disabling an account, or supports disable by means of resetting the user’s password, the Identity Manager provisioning engine disables the account. You can perform the disable by setting the user account to a randomly generated, non-displayed, non-retained password. When the account is enabled, the system randomly generates a new password, which is displayed in the Identity Manager Administrative interface or emailed to the user.

Enabling Pass-Through Authentication for Resource Types

Use the following general steps to enable pass-through authentication in a resource type:

To Enable Pass-Through Authentication on a Resource Type

1. Ensure that the adapter’s getFeatures() method returns ResourceAdapter.ACCOUNT_LOGIN as a supported feature.

   • If your custom adapter overrides the ResourceAdapterBase implementation, add the following code.

     public GenericObject getFeatures() { GenericObject genObj = super.getFeatures(); genObj.put(Features.ACCOUNT_RENAME, Features.ACCOUNT_RENAME); .. other features supported by this Resource Adapter … return genObj; }

   • If your custom adapter does not override the getFeatures() implementation in the ResourceAdapterBase class, it will inherit the getFeatures() implementation that is exported for ACCOUNT_LOGIN by default.

2. Add the <LoginConfigEntry> element to the adapter’s prototypeXML.

3. Implement the adapter’s authenticate() method.

   The authenticate() method authenticates the user against the resource by using the authentication property name/value pairs provided in the loginInfo map. If authentication succeeds, be sure that the authenticated unique ID is returned in the WavesetResult by adding a result as follows:

   result.addResult(Constants.AUTHENTICATED_IDENTITY, accountID);

   If authentication succeeded, but the user’s password was expired, then in addition to the identity added above, also add the password expired indicator to the result to be returned. This will ensure that the user will be forced to change their password on at least resource upon next login to Identity Manager.

   result.addResult(Constants.RESOURCE_PASSWORD_EXPIRED, new Boolean(true));

   If authentication fails (because the user name or password is invalid), then:

   throw new WavesetException("Authentication failed for " + uid + ".");

How to Write Active Sync-Enabled Adapter Methods

Active Sync-specific methods provide the mechanism for updating Identity Manager, which is the primary purpose of your Active Sync-enabled adapter adapter. These methods are based on pulling information from the authoritative resource. In addition, you use these methods to start, stop, and schedule the adapter.

The methods you are going to write in this section of the adapter are based on generic methods supplied with the skeleton adapter file. You must edit some of these methods, which are categorized by task.

The following sections describe general guidelines for creating Active Sync-enabled adapter methods:

• Initializing and Scheduling the Adapter

• Polling the Resource

• Storing and Retrieving Adapter Attributes

• Updating the Identity Manager Repository

• Shutting Down the Adapter

Initializing and Scheduling the Adapter

You initialize and schedule the adapter by implementing the init() and poll() methods.

The init() method is called when the adapter manager loads the adapter. There are two methods for loading the adapter:

• The manager can load the adapter at system startup if the adapter startup type is automatic.

• An administrator loads the adapter by clicking Start on the Resources page if the adapter startup type is manual.

In the initialization process, the adapter can perform its own initialization. Typically, this involves initializing logging (with the ActiveSyncUtil class), and any adapter-specific initialization such as registering with a resource to receive update events.

If an exception is thrown, the adapter is shut down and unloaded.

Polling the Resource

All of the adapter’s work is performed by the poll() method. Scheduling the adapter requires setting up a poll() method to search for and retrieve changed information on the resource.

This method is the main method of the Active Sync-enabled adapter. The adapter manager calls the poll() method to poll the remote resource for changes. The call then converts the changes into IAPI calls and posts them back to a server. This method is called on its own thread and can block for as long as needed.

It should call its ActiveSyncUtil instance’s isStopRequested method and return when true. Check isStopRequested as part of the loop condition when looping through changes.

To configure defaults for polling, you can set the polling-related resource attributes in the adapter file. Setting these polling-related attributes provides administrators with a means to later use the Identity Manager interface to set the start time and date for the poll interval and the length of the interval.

Scheduling Parameters

You use the following scheduling parameters in Active Sync-enabled adapters:

• RA_SCHEDULE_INTERVAL

• RA_SCHEDULE_INTERVAL_COUNT

• RA_SCHEDULE_START_TIME

• RA_SCHEDULE_START_DATE

See Table 9–6 for a description of these parameters.

Scheduling Parameters in the prototypeXML

The scheduling parameters are present in the string constant ActiveSync. ACTIVE_SYNC_STD_RES_ATTRS_XML, along with all other general Active Sync-related resource attributes.

The following table describes the usage of scheduling parameters using some sample polling scenarios.

Storing and Retrieving Adapter Attributes

Most Active Sync-enabled adapters are also standard adapters, where a single Java class both extends ResourceAdapterBase (or AgentResourceAdapter) and implements the Active Sync interface.

The following example shows how to retrieve the attribute and pass the update through to the base.

Example 9–5 Attribute Retrieval and Update

public Object getAttributeValue(String name) throws WavesetException {
return getResource().getResourceAttributeVal(name); }
public void setAttributeValue(String name, Object value) throws WavesetException {
getResource().setResourceAttributeVal(name,value);

Updating the Identity Manager Repository

When an update is received, the adapter uses the IAPI classes, notably IAPIFactory to:

• Collect the changed attributes

• Map the changes to a unique Identity Manager object

• Update that object with the changed information

Mapping the Changes to the Identity Manager Object

Using the Active Sync event parameter configurator for the resource, IAPIFactory.getIAPI constructs an IAPI object, either IAPIUser or IAPIProcess from a map of changed attributes. If an exclusion rule (iapi_create, iapi_delete, or iapi_update) is configured for the resource, IAPIFactory checks if the account is excluded. If a non-null object is created and returned by the Factory, the adapter can modify the IAPI object (for example, by adding a logger), then submits it.

When the object is submitted, the form associated with the resource is expanded with the object view before the view is checked in. For more information about forms and views, see Deployment Reference.

In SkeletonActiveSyncResourceAdapter, this process is handled in the buildEvent and processUpdates methods.

Shutting Down the Adapter

No system requirements are associated with adapter shutdown. Identity Manager calls the shutdown method, which is an opportunity for your adapter to cleanup any objects still in use from the polling loop.

Configure the Adapter to Support Pass-Through Authentication

Identity Manager uses pass-through authentication to grant users and administrators access through one or more different passwords. Identity Manager manages pass-through authentication through the implementation of:

• Login applications (collection of login module groups)

• Login module groups (ordered set of login modules)

• Login modules (sets authentication for each assigned resource and specify one of several success requirements for authentication)

You configure a custom adapter to support pass-through authentication by

• Implementing the authenticate() method appropriately

• Including the account.LOGIN feature in the getFeatures() method map (com.waveset.adapter.ResourceAdapter.ACCOUNT_LOGIN)

• Including the <LoginConfigEntry> section in the resource’s prototypeXML

When configuring a custom resource adapter to support an interactive login, you must enable the adapter to request additional information from a user during log in and after that user submits the initial login page.

The adapter authenticate() method controls whether the login becomes interactive. The authenticate() method’s return values trigger the interactive login so the authenticate() is called again with the results of the next login page until the authenticate() method decides the login

• Fails by throwing an exception

• Succeeds by returning the account ID of the authenticated account in the WavesetResult as usual

To be interactive, the adapter must return a WavesetResult that

• Does not contain ResultItems with a Constants.AUTHENTICATED_GUID type or Constants.AUTHENTICATED_IDENTITY type

• Does contain ResultItems that are used to dynamically build a form for the next page of the login

Each ResultItem corresponds to a field in the form. ResultItems must have the Constants.CONTINUE_AUTHENTICATION_ATTR type with values in the following format:

label|attrName|displayType|prompt|’isId’

Where

• label is a string containing a label or none.

• attrName is the login attribute name that is passed into the next authenticate() method call as a key in the loginInfo HashMap.

• displayType describes the type of form field to use. displayType values include

  • text

  • secret

  • label

  • checkbox

  prompt corresponds to the title or label of the form field.

• isId is an optional string.

  If you use the isId string, the value of the form field is added to the loginInfo HashMap with the key Constants.ACCOUNT_ID and the value of the field.

The following ResultItem types are also “round-tripped” and returned in the loginInfo HashMap on the next authenticate() call:

• Constants.CONTINUE_AUTHENTICATION_ACCOUNT_HANDLE keep track of which user or account is in the process of being authenticated.

• Constants.CONTINUE_AUTHENTICATION_PREVIOUS_ATTR remove previous authentication attributes from the loginInfo, so the loginInfo does not contain an “old” authentication attr.

Define the Resource Object Components

This section describes how to define the following resource object components:

• Defining Resource Object Classes

• Defining Resource ObjectTypes

• Defining Resource Object Features

• Defining Resource Object Attributes

• Defining Resource Forms

Defining Resource Object Classes

Object classes are handled differently for LDAP-based resource objects than for other resource objects.

LDAP-Based Resource Objects

LDAP-based resource objects can consist of more than one LDAP object class, where each object class is an extension of its parent object class. However, within LDAP, the complete set of these object classes is viewed and managed as a single object type within LDAP.

To manage this type of resource object within Identity Manager, include the XML element <ObjectClasses> within the <ObjectType> definition. The <ObjectClasses> element allows you to define the set of object classes that is associated with this <ObjectType> as well as the relationship of classes to each other.

Non-LDAP-Based Resource Objects

For non-LDAP-based resource objects, you can use the <ObjectType> to represent information other than the resource object type name.

In the following example, the primary attribute defines the object class to be used when creating and updating an object of this type. In this case, inetorgperson is the object class that is defined as the primary one because it is a subclass of the other listed object classes. The operator attribute specifies whether the list of object classes should be treated as one (logical AND) or treated as unique classes (logical OR) when listing or getting an object of this type. In this case, Identity Manager performs an AND operation on these object classes prior to any list or get requests for this object type.

Example 9–6 Using inetorgperson Object Class

<ObjectClasses primary=’inetorgperson’ operator=’AND’>\n"+
<ObjectClass name=’person’/>\n"+ <ObjectClass name=’organizationalPerson’/>\n"+
<ObjectClass name=’inetorgperson’/>\n"+ </ObjectClasses>\n"+

In the next example, all requests to create and/or update resource objects of this type are done using the groupOfUniqueNames object class. All list and get requests will query for all objects whose object class is either groupOfNames or groupOfUniqueNames.

Example 9–7 Using groupOfUniqueNames Object Class

<ObjectClasses primary=’groupOfUniqueNames’ operator=’OR’>\n"+
<ObjectClass name=’groupOfNames’/>\n"+ <ObjectClass name=’groupOfUniqueNames’/>\n"+
</ObjectClasses>\n"+

In this example, only one object class is defined so all create, get, list, and update operations are performed using object class organizationalUnit.

Example 9–8 Using organizationalUnit Object Class

<ObjectClasses operator=’AND’>\n"+ <ObjectClass name=’organizationalUnit’/>\n"+ </ObjectClasses>\n"+

Because there is only one object class, you can exclude the <ObjectClasses> section. If you exclude the <ObjectClasses> section, the object class defaults to the <ObjectType> name attribute value. However, if you want the object type name to differ from the resource object class name, you must include the <ObjectClasses> section with the single <ObjectClass> entry.

Defining Resource ObjectTypes

Resource Object types uniquely define a specific type of resource, and you define object types in the adapter’s prototypeXML string.

The XML <ObjectTypes> element is a container within the adapter’s prototypeXML string that contains one or more object type definitions to be managed on that resource. This <ObjectTypes> element fully describes the resource-specific object to Identity Manager, including the following:

• A list of specific object classes contained in the object type (required only for LDAP-compliant directories)

• A list of supported features

• A list of object type-specific attributes that are available within Identity Manager for editing and searching

The following table describes the supported attributes of the <ObjectType> element.

The following example shows ObjectType definitions:

Example 9–9 Example ObjectType Definitions

static final String prototypeXml =
"<Resource name=’Skeleton’ class= ’com.waveset.adapter.sample.SkeletonStandardResourceAdapter’
typeString=’Skeleton of a resource adapter’ typeDisplayString=’"+Messages.RESTYPE_SKELETON+"’>\n"+
  " <ObjectTypes>\n"+ 
  " <ObjectType name=’Group’ icon=’group’>\n"+ 
… other content defined below will go here … 
  " </ObjectType>\n"+ 
  " <ObjectType name=’Role’ icon=’ldap_role’>\n"+ 
… other content defined below will go here … 
  " </ObjectType>\n"+ 
  " <ObjectType name=’Organization’ icon=’folder_with_org’ container=’true’>\n"+ 
… other content defined below will go here … 
  "</ObjectType>\n"+ 
" </ObjectTypes>\n”+

Defining Resource Object Features

The <ObjectFeatures> section specifies a list of one or more features supported by this object type, where each object feature is directly tied to the implementation of the associated object type method in the resource adapter.

Each ObjectFeature definition must contain the name attribute, which specifies a feature name. The create and update features can specify a form attribute, which defines the resource form used to process create and update features. If you do not specify a form attribute, Identity Manager processes the create and update features with the same form used by all resources of a given type.

The following table describes the object feature mappings.

In the following example, the <ObjectFeatures> section includes all supported object features. Your resource adapter can support all of these features or just a subset of features. The more object features your adapter supports, the richer the object management function within Identity Manager.

Example 9–10 <ObjectFeatures> Section Including all Supported Object Features

 <ObjectFeatures>\n"+
   <ObjectFeature name=’create’ form=’My Create Position Form’/>
   <ObjectFeature name=’update’ form=’My Update Position Form’/>
   <ObjectFeature name=’create’/>\n"+
   <ObjectFeature name=’delete’/>\n"+
   <ObjectFeature name=’rename’/>\n"+
   <ObjectFeature name=’saveas’/>\n"+
   <ObjectFeature name=’find’/>\n"+
   <ObjectFeature name=’list’/>\n"+
   <ObjectFeature name=’view’/>\n"+
</ObjectFeatures>\n"+

Defining Resource Object Attributes

The <ObjectAttributes> section specifies the set of attributes to be managed and queried in Identity Manager. Each <ObjectAttribute> element name should be the same as the native resource attribute name. Unlike user attributes in Identity Manager, no attribute mapping is specified. Use only the native attribute names.

The following table describes attributes that are required for <ObjectAttributes>.

The following example shows an <ObjectAttributes> section defined in an <ObjectType>.

Example 9–11 <ObjectAttributes> Section Defined in an <ObjectType>

<ObjectAttributes idAttr=’dn’ displayNameAttr=’cn’ descriptionAttr=
       ’description’>\n"+
    <ObjectAttribute name=’cn’ type=’string’/>\n"+
    <ObjectAttribute name=’description’ type=’string’/>\n"+
    <ObjectAttribute name=’owner’ type=’distinguishedname’
namingAttr=’cn’/>\n"+
    <ObjectAttribute name=’uniqueMember’ type=’dn’ namingAttr=’cn’ />\n"+
 </ObjectAttributes>\n"+

The following table describes the <ObjectAttribute> attributes.

The methods in the resource adapter object type implementation are responsible for coercing all string values into the appropriate type based on the resource attribute name.

Defining Resource Forms

You must provide the following resource forms:

• A ResourceForm named <resource type> Create <object type> Form for each resource <ObjectType> that supports the Create feature.

  For example, AIX Create Group Form or LDAP Create Organizational Unit Form

• A ResourceForm named <resource type> Update <object type> Form for each resource <ObjectType> that supports the Update feature.

  For example, AIX Update Group Form or LDAP Update Organizational Unit Form

You can also assign an optional form that processes incoming data before storing it in Identity Manager. This resource form is a mechanism that transforms incoming data from the schema map and applies the transformed data to the User view. The sample form also performs actions, such as enabling and disabling an account, that are based on specific incoming data values such as employee status.

The following table describes attributes contained in the top-level namespace.

All values are strings unless otherwise specified.