1. Download and extract the OpenDJ zip archive from the OpenDJ Project page.

2. Install OpenDJ using the command-line setup. During the install, import the LDIF data required for this sample:

   $ cd /path/to/opendj
   $ ./setup --cli \
   --hostname localhost \
   --ldapPort 1389 \
   --rootUserDN "cn=Directory Manager" \
   --rootUserPassword password \
   --adminConnectorPort 4444 \
   --baseDN dc=com \
   --ldifFile /path/to/openidm/samples/sample2/data/Example.ldif \
   --acceptLicense \
   --no-prompt
   ...
   Configuring Directory Server ..... Done.
   Importing LDIF file /path/to/openidm/samples/sample2/data/Example.ldif ...... Done.
   Starting Directory Server ...... Done..
   ...

1. Reconcile the repository by running the following command:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/recon?_action=recon&mapping=systemLdapAccounts_managedUser&waitForCompletion=true"
   {
     "state": "SUCCESS",
     "_id": "f3c618aa-cc3b-49ed-9a3a-00b012db2513"
   }
        

   The reconciliation operation creates the two users from the LDAP server in the OpenIDM repository, assigning the new objects random unique IDs.

2. To retrieve the users from the repository, query their IDs as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 2,
     "result": [
       {
         "_rev": "0",
         "_id": "0a5546d6-149b-4f8b-b3be-4afa8a267d45"
       },
       {
         "_rev": "0",
         "_id": "840394b9-ced0-4f13-a5ad-6a0d825f0705"
       }
     ]
   }

3. To retrieve individual user objects, include the ID in the URL, for example:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user/0a5546d6-149b-4f8b-b3be-4afa8a267d45"
   {
     "displayName": "Babara Jensen",
     "stateProvince": "",
     "userName": "bjensen",
     "postalAddress": "",
     "effectiveAssignments": {},
     "roles": [
       "openidm-authorized"
     ],
     "country": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "Barbara",
     "address2": "",
     "lastPasswordAttempt": "Mon Nov 24 2014 21:17:19 GMT+0200 (SAST)",
     "passwordAttempts": "0",
     "sn": "Jensen",
     "mail": "bjensen@example.com",
     "city": "",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "0a5546d6-149b-4f8b-b3be-4afa8a267d45",
     "_rev": "1",
     "accountStatus": "active",
     "description": "Created for OpenIDM",
     "telephoneNumber": "1-360-229-7105"
   }       

1. Log in to the Admin UI at the URL https://localhost:8443/admin as the default administrative user (openidm-admin) with password openidm-admin.

   The first time you log into the Admin UI, you are prompted to change your password. If you do not want to change your password at this time, simply click X to close this window, and continue with the sample.

2. Select the Mappings tab.

   This tab shows one configured mapping, from the ldap server to the OpenIDM repository (managed/user).

   

3. Click anywhere on the mapping and click Reconcile Now.

   The reconciliation operation creates the two users from the LDAP server in the OpenIDM repository.

4. Retrieve the users in the repository by clicking the User View link at the top right of the Admin UI.

   This link opens the User View UI. If you did not change your password in the first step, you are prompted to change your password again. You can bypass this by simply clicking X to close the password prompt window.

5. Select the Users tab.

   

   The two users from the LDAP server have been reconciled to the OpenIDM repository.

6. To retrieve the details of a specific user, click that username on the Users tab.

   The following image shows the details of user bjensen.

   

1. Reconcile the repository over the REST interface by running the following command:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/recon?_action=recon&mapping=systemLdapAccounts_managedUser&waitForCompletion=true"
   {
     "state": "SUCCESS",
     "_id": "027e25e3-7a33-4858-9080-161c2b40a6bf"
   }

   The reconciliation operation returns a reconciliation run ID and the status of the operation. Reconciliation creates user objects from LDAP in the OpenIDM repository, assigning the new objects random unique IDs.

2. To retrieve the users from the repository, query their IDs as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 2,
     "result": [
       {
         "_rev": "0",
         "_id": "2cb34789-ee67-4f50-88f2-022460c37253"
       },
       {
         "_rev": "0",
         "_id": "625942ac-3cb8-47aa-9de1-217d24967b3b"
       }
     ]
   }

3. To retrieve individual user objects, include the ID in the URL, for example:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user/625942ac-3cb8-47aa-9de1-217d24967b3b"
   {
     "displayName": "Babara Jensen",
     "stateProvince": "",
     "userName": "bjensen",
     "postalAddress": "",
     "effectiveAssignments": {},
     "roles": [
       "openidm-authorized"
     ],
     "country": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "Barbara",
     "address2": "",
     "lastPasswordAttempt": "Tue Nov 25 2014 12:29:15 GMT+0200 (SAST)",
     "passwordAttempts": "0",
     "sn": "Jensen",
     "mail": "bjensen@example.com",
     "city": "",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "625942ac-3cb8-47aa-9de1-217d24967b3b",
     "_rev": "1",
     "description": "Created for OpenIDM",
     "accountStatus": "active",
     "telephoneNumber": "1-360-229-7105"
   }

4. Test the second mapping by creating a user in the OpenIDM repository.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '{
       "mail":"fdoe@example.com",
       "sn":"Doe",
       "telephoneNumber":"555-1234",
       "userName":"fdoe",
       "givenName":"Felicitas",
       "description":"Felicitas Doe",
       "displayName":"fdoe"}' \
    "https://localhost:8443/openidm/managed/user?_action=create"
   {
     "displayName": "fdoe",
     "stateProvince": "",
     "userName": "fdoe",
     "postalAddress": "",
     "effectiveAssignments": {},
     "roles": [
       "openidm-authorized"
     ],
     "country": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "Felicitas",
     "address2": "",
     "lastPasswordAttempt": "Tue Nov 25 2014 12:49:06 GMT+0200 (SAST)",
     "passwordAttempts": "0",
     "sn": "Doe",
     "mail": "fdoe@example.com",
     "city": "",
     "_rev": "1",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "c462fac4-528a-45c5-ba76-d2744952d418",
     "description": "Felicitas Doe",
     "accountStatus": "active",
     "telephoneNumber": "555-1234"
   }

5. By default, implicit synchronization is enabled for mappings from the managed/user repository to any external resource. This means that when you update a managed object, any mappings defined in the sync.json file that have the managed object as the source are automatically executed to update the target system. For more information, see Section 12.3.2, "Synchronization Mappings File" in the Integrator's Guide.

   Test that the implicit reconciliation has been successful by querying the users in the LDAP directory over REST, as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/ldap/account?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 3,
     "result": [
       {
         "_id": "uid=jdoe,ou=People,dc=example,dc=com",
         "dn": "uid=jdoe,ou=People,dc=example,dc=com"
       },
       {
         "_id": "uid=bjensen,ou=People,dc=example,dc=com",
         "dn": "uid=bjensen,ou=People,dc=example,dc=com"
       },
       {
         "_id": "uid=fdoe,ou=People,dc=example,dc=com",
         "dn": "uid=fdoe,ou=People,dc=example,dc=com"
       }
     ]
   }

   Note the new entry for user fdoe.

6. Query the complete entry by including fdoe's ID in the URL.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/ldap/account/uid=fdoe,ou=People,dc=example,dc=com"
   {
     "_id": "uid=fdoe,ou=People,dc=example,dc=com",
     "dn": "uid=fdoe,ou=People,dc=example,dc=com",
     "mail": "fdoe@example.com",
     "uid": "fdoe",
     "ldapGroups": [],
     "cn": "fdoe",
     "givenName": "Felicitas",
     "telephoneNumber": "555-1234",
     "description": "Felicitas Doe",
     "sn": "Doe"
   }

1. Log in to the Admin UI at the URL https://localhost:8443/admin as the default administrative user (openidm-admin) with password openidm-admin.

   The first time you log into the Admin UI, you are prompted to change your password. If you do not want to change your password at this time, simply click X to close this window, and continue with the sample.

2. Select the Mappings tab.

   This tab shows two configured mappings, one from the ldap server to the OpenIDM repository (managed/user) and one from the OpenIDM repository to the ldap server.

   

3. Click anywhere on the first mapping and click Reconcile Now.

   

   The reconciliation operation creates the two users from the LDAP server in the OpenIDM repository.

4. Retrieve the users in the repository by clicking the User View link at the top right of the Admin UI.

   This link opens the User View UI. If you did not change your password in the first step, you are prompted to change your password again. You can bypass this by simply clicking X to close the password prompt window.

5. Select the Users tab.

   

   The two users from the LDAP server have been reconciled to the OpenIDM repository.

6. To retrieve the details of a specific user, click that username on the Users tab.

   The following image shows the details of user bjensen.

   

7. Add a new user in the OpenIDM repository by clicking Add User on the Users tab.

   Complete the user details and click Create.

   The following image shows a new record being created for user fdoe.

   

8. By default, implicit synchronization is enabled for mappings from the managed/user repository to any external resource. This means that when you update a managed object, any mappings defined in the sync.json file that have the managed object as the source are automatically executed to update the target system. For more information, see Section 12.3.2, "Synchronization Mappings File" in the Integrator's Guide.

   To test that the implicit reconciliation has been successful, look at fdoe's record in the User View UI. At the bottom of the user profile, the Linked Systems panel indicates the external resource to which this user entry is mapped.

   The following image shows that fdoe now exists in the linked resource ldap account, and shows her entry as it appears on the LDAP server.

   

1. Reconcile the repository over the REST interface by running the following command:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/recon?_action=recon&mapping=systemLdapAccounts_managedUser&waitForCompletion=true"
   {
     "state": "SUCCESS",
     "_id": "8a25d1ca-c0f3-4e0f-82a0-b5c346282782"
   }

   The reconciliation operation returns a reconciliation run ID and the status of the operation. Reconciliation creates user objects from LDAP in the OpenIDM repository, assigning the new objects random unique IDs.

2. To retrieve the users from the repository, query their IDs as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 2,
     "result": [
       {
         "_rev": "0",
         "_id": "40f41f52-44a0-40fe-83ab-a95b92a25805"
       },
       {
         "_rev": "0",
         "_id": "cec9e2d7-cb6c-4622-94a8-2cb43695476f"
       }
     ]
   }

3. To retrieve individual user objects, include the ID in the URL. The following request retrieves the user object for John Doe:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user/cec9e2d7-cb6c-4622-94a8-2cb43695476f"
   {
     "displayName": "John Doe",
     "userName": "jdoe",
     "stateProvince": "",
     "postalAddress": "",
     "ldapGroups": [
       "cn=openidm,ou=Groups,dc=example,dc=com"
     ],
     "effectiveAssignments": {},
     "roles": [
       "openidm-authorized"
     ],
     "country": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "John",
     "address2": "",
     "lastPasswordAttempt": "Wed Nov 26 2014 14:30:58 GMT+0200 (SAST)",
     "passwordAttempts": "0",
     "sn": "Doe",
     "mail": "jdoe@example.com",
     "city": "",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "cec9e2d7-cb6c-4622-94a8-2cb43695476f",
     "_rev": "1",
     "description": "Created for OpenIDM",
     "accountStatus": "active",
     "telephoneNumber": "1-415-599-1100"
   }

   Note that John Doe's user object contains an ldapGroups property, the value of which indicates his groups on the LDAP server:

   "ldapGroups":["cn=openidm,ou=Groups,dc=example,dc=com"]

4. Update John Doe's ldapGroups property, to change his membership from the openidm group to the openidm2 group.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '[
       {
         "operation":"replace",
         "field":"/ldapGroups",
         "value": ["cn=openidm2,ou=Groups,dc=example,dc=com"]
       }
    ]' \
    "https://localhost:8443/openidm/managed/user?_action=patch&_queryId=for-userName&uid=jdoe"
   {
     "displayName": "John Doe",
     "userName": "jdoe",
     "stateProvince": "",
     "postalAddress": "",
     "effectiveAssignments": {},
     "ldapGroups": [
       "cn=openidm2,ou=Groups,dc=example,dc=com"
     ],
     "roles": [
       "openidm-authorized"
     ],
     "city": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "John",
     "lastPasswordAttempt": "Wed Nov 26 2014 14:30:58 GMT+0200 (SAST)",
     "address2": "",
     "passwordAttempts": "0",
     "sn": "Doe",
     "mail": "jdoe@example.com",
     "country": "",
     "_rev": "2",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "cec9e2d7-cb6c-4622-94a8-2cb43695476f",
     "description": "Created for OpenIDM",
     "accountStatus": "active",
     "telephoneNumber": "1-415-599-1100"
   }   

   This command changes John Doe's ldapGroups property in the OpenIDM repository, from "cn=openidm,ou=Groups,dc=example,dc=com" to "cn=openidm2,ou=Groups,dc=example,dc=com". As a result of implicit synchronization, the change is propagated to the LDAP server. John Doe is removed from the first LDAP group and added to the second LDAP group in OpenDJ.

5. You can verify this change by querying John Doe's record on the LDAP server, as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/ldap/account/uid=jdoe,ou=People,dc=example,dc=com"
   {
     "_id": "uid=jdoe,ou=People,dc=example,dc=com",
     "telephoneNumber": "1-415-599-1100",
     "description": "Created for OpenIDM",
     "sn": "Doe",
     "dn": "uid=jdoe,ou=People,dc=example,dc=com",
     "ldapGroups": [
       "cn=openidm2,ou=Groups,dc=example,dc=com"
     ],
     "uid": "jdoe",
     "cn": "John Doe",
     "givenName": "John",
     "mail": "jdoe@example.com"
   }
        

1. Log in to the Admin UI at the URL https://localhost:8443/admin as the default administrative user (openidm-admin) with password openidm-admin.

   The first time you log into the Admin UI, you are prompted to change your password. If you do not want to change your password at this time, simply click X to close this window, and continue with the sample.

2. Select the Mappings tab.

   This tab shows two configured mappings, one from the ldap server to the OpenIDM repository (managed/user) and one from the OpenIDM repository to the ldap server.

   

3. Click anywhere on the first mapping and click Reconcile Now.

   

   The reconciliation operation creates the two users from the LDAP server in the OpenIDM repository.

4. Retrieve the users in the repository by clicking the User View link at the top right of the Admin UI.

   This link opens the User View UI. If you did not change your password in the first step, you are prompted to change your password again. You can bypass this by simply clicking X to close the password prompt window.

5. Select the Users tab.

   

   The two users from the LDAP server have been reconciled to the OpenIDM repository.

6. To retrieve the details of a specific user, click that username on the Users tab.

   The following image shows the details of user jdoe.

   

   Note the Linked Systems section of John Doe's profile. The Linked Resource item indicates the external resource on which John Doe's managed object is mapped, in this case, ldap account.

   In this linked resource, John Doe's ldapGroups are displayed. Currently, John Doe is a member of cn=openidm,ou=Groups,dc=example,dc=com.

7. Update John Doe's ldapGroups property, in the repository, to change his membership from the openidm group to the openidm2 group.

   In the current default version of the User View UI, only specific properties of a managed object can be edited. It is therefore not possible to update John Doe's ldapGroups property using the UI.

   Instead, update his managed/user object over REST, as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '[
       {
         "operation":"replace",
         "field":"/ldapGroups",
         "value": ["cn=openidm2,ou=Groups,dc=example,dc=com"]
       }
    ]' \
    "https://localhost:8443/openidm/managed/user?_action=patch&_queryId=for-userName&uid=jdoe"
   {
     "displayName": "John Doe",
     "userName": "jdoe",
     "stateProvince": "",
     "postalAddress": "",
     "effectiveAssignments": {},
     "ldapGroups": [
       "cn=openidm2,ou=Groups,dc=example,dc=com"
     ],
     "roles": [
       "openidm-authorized"
     ],
     "city": "",
     "effectiveRoles": [
       "openidm-authorized"
     ],
     "givenName": "John",
     "lastPasswordAttempt": "Wed Nov 26 2014 14:30:58 GMT+0200 (SAST)",
     "address2": "",
     "passwordAttempts": "0",
     "sn": "Doe",
     "mail": "jdoe@example.com",
     "country": "",
     "_rev": "2",
     "lastPasswordSet": "",
     "postalCode": "",
     "_id": "cec9e2d7-cb6c-4622-94a8-2cb43695476f",
     "description": "Created for OpenIDM",
     "accountStatus": "active",
     "telephoneNumber": "1-415-599-1100"
   }   

   This command changes John Doe's ldapGroups property in the OpenIDM repository, from "cn=openidm,ou=Groups,dc=example,dc=com" to "cn=openidm2,ou=Groups,dc=example,dc=com". As a result of implicit synchronization, the change is propagated to the LDAP server. John Doe is removed from the first LDAP group and added to the second LDAP group in OpenDJ.

8. You can verify this change by reloading John Doe's user profile in the User View UI, and looking at the value of his ldapGroups property in the Linked Systems panel.

   The following image shows the updated record for John Doe, with a new ldapGroups value of cn=openidm2,ou=Groups,dc=example,dc=com.

   

1. Reconcile the repository over the REST interface for the group mapping, systemLdapGroups_managedGroup by running the following command:

   $  curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/recon?_action=recon&mapping=systemLdapGroups_managedGroup&waitForCompletion=true"

   The reconciliation operation returns a reconciliation run ID, and the status of the operation.

2. With the configuration of sample 2d, OpenIDM creates group objects from LDAP in OpenIDM. To list group objects by ID, run a query over the REST interface.

   $  curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/group?_queryFilter=true"

   The resulting JSON object should include content similar to the following.

    {
      "result" : [ {
         "dn" : "cn=openidm,ou=Groups,dc=example,dc=com",
         "_id" : "837df489-35d6-48d1-81a5-23792b49838a",
         "_rev" : "1",
         "description" : [ ],
         "uniqueMember" : [ "uid=jdoe,ou=People,dc=example,dc=com" ],
         "name" : [ "openidm" ]
      }, {
         "dn" : "cn=openidm2,ou=Groups,dc=example,dc=com",
         "_id" : "7575c1c7-86cf-43bc-bf1d-5c9cfc539124",
         "_rev" : "1",
         "description" : [ ],
         "uniqueMember" : [ "uid=bjensen,ou=People,dc=example,dc=com" ],
         "name" : [ "openidm2" ]
      } ],
         "resultCount" : 2,
         "pagedResultsCookie" : null,
         "remainingPagedResults" : -1
    }

1. Log in to the Admin UI at the URL https://localhost:8443/admin as the default administrative user (openidm-admin) with password openidm-admin.

   The first time you log into the Admin UI, you are prompted to change your password. If you do not want to change your password at this time, click X to close this window, and continue with the sample.

2. Select the Mappings tab.

   This tab shows three configured mappings, from the ldap server accounts repository to the OpenIDM repository (managed/user), from the OpenIDM repository back to the ldap server, and from the ldap server group accounts repository to the OpenIDM managed/group repository.

   

3. Click anywhere on the third mapping and click Reconcile Now.

   

   The reconciliation operation creates the two groups from the LDAP server in the OpenIDM repository.

4. Retrieve the groups in the repository by clicking the Correlation link below the mapping. Scroll down to Data Association Management.

   

   The two groups from the LDAP server (source) have been reconciled to the OpenIDM repository (target).

1. Install, configure, and start the .NET connector server on the machine that is running an Active Directory Domain Controller or on a workstation on which the Microsoft Active Directory PowerShell module is installed.

   For instructions on installing the .NET connector server, see Procedure 11.1, "Installing the .NET Connector Server" in the Integrator's Guide.

2. Configure OpenIDM to connect to the .NET connector server.

   To do so, copy the remote connector provisioner file from the openidm/samples/provisioners directory to the openidm/conf directory, and edit the file according to your configuration.

   $ cd /path/to/openidm
   $ cp samples/provisioners/provisioner.openicf.connectorinfoprovider.json conf/

   For instructions on editing this file, see Procedure 11.4, "Configuring OpenIDM to Connect to the .NET Connector Server" in the Integrator's Guide.

3. Download the PowerShell Connector Toolkit archive (mspowershell-connector-1.4.1.0.zip) from ForgeRock Backstage.

   Extract the archive and move the MsPowerShell.Connector.dll to the folder in which the connector server application (connectorserver.exe) is located.

4. Copy the PowerShell scripts from the tools folder in this sample directory, to the machine on which the connector server is installed.

   C:\>dir openidm\powershell2AD\tools
   Directory of C:\openidm\powershell2AD\tools
   
   11/27/2014  12:53 PM    <DIR>          .
   11/27/2014  12:53 PM    <DIR>          ..
   11/26/2014  02:32 PM             2,813 ADAuthenticate.ps1
   11/26/2014  02:32 PM             8,546 ADCreate.ps1
   11/26/2014  02:32 PM             2,530 ADDelete.ps1
   11/26/2014  02:32 PM             2,617 ADResolveUsername.ps1
   11/26/2014  02:32 PM             8,644 ADSchema.ps1
   11/26/2014  02:32 PM             3,458 ADSearch.ps1
   11/26/2014  02:32 PM             4,585 ADSync.ps1
   11/26/2014  02:32 PM             2,075 ADTest.ps1
   11/26/2014  02:32 PM             8,488 ADUpdate.ps1
                  9 File(s)         43,756 bytes
                  2 Dir(s)  23,696,863,232 bytes free
   
   C:\>

5. Edit the PowerShell search and sync scripts (ADSearch.ps1) and (ADSync.ps1) to specify the base suffix for your Active Directory Domain Controller.

   Specifically, change the value of the $searchBase parameter in these files to match the suffix in your environment. The default suffix is:

   $searchBase = 'CN=Users,DC=example,DC=com'

6. Copy the sample connector configuration for the PowerShell connector from the samples directory to your conf directory.

   $ cd /path/to/openidm
   $ cp samples/provisioners/provisioner.openicf-adpowershell.json conf/

   The sample connector configuration assumes that the scripts are located in C:/openidm/samples/powershell2AD/tools/. If you copied your scripts to a different location, adjust your connector configuration file accordingly.

   Note that the OpenICF framework requires the path to use forward slash characters and not the backslash characters that you would expect in a Windows path.

   In addition, make sure that the value of the "connectorHostRef" property in the connector configuration file matches the value that you specified in the remote connector configuration file, in step 2 of this procedure. For example:

   "connectorHostRef" : "dotnet",

   The host, port, login and password of the machine on which Active Directory runs do not need to be specified here. By default the Active Directory cmdlets pick up the first available Domain Controller. In addition, the scripts are executed using the credentials of the .Net connector server.

1. Test the connector configuration, and whether OpenIDM is able to connect to the .NET connector server with the following request.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/system?_action=test"
   [
     {
       "ok": true,
       "connectorRef": {
         "bundleVersion": "1.4.1.0",
         "bundleName": "MsPowerShell.Connector",
         "connectorName": "Org.ForgeRock.OpenICF.Connectors.MsPowerShell.MsPowerShellConnector"
       },
       "objectTypes": [
         "__ALL__",
         "group",
         "account"
       ],
       "config": "config/provisioner.openicf/adpowershell",
       "enabled": true,
       "name": "adpowershell"
     }
   ] 

2. Query the users in your Active Directory with the following request:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/adpowershell/account?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 1257,
     "result": [
       {
         "_id": "7c41496a-9898-4074-a537-bed696b6be92",
         "distinguishedName": "CN=Administrator,CN=Users,DC=example,DC=com"
       },
       {
         "_id": "f2e08a5c-473f-4798-a2d5-d5cc27c862a9",
         "distinguishedName": "CN=Guest,CN=Users,DC=example,DC=com"
       },
       {
         "_id": "99de98a3-c125-48dd-a7c2-e21f1488ab06",
         "distinguishedName": "CN=Ben Travis,CN=Users,DC=example,DC=com"
       },
       {
         "_id": "0f7394cc-c66a-404f-ad6d-38dbb4b6526d",
         "distinguishedName": "CN=Barbara Jensen,CN=Users,DC=example,DC=com"
       },
       {
         "_id": "3e6fa858-ed3a-4b58-9325-1fca144eb7c7",
         "distinguishedName": "CN=John Doe,CN=Users,DC=example,DC=com"
       },
       {
         "_id": "6feef4a0-b121-43dc-be68-a96703a49aba",
         "distinguishedName": "CN=Steven Carter,CN=Users,DC=example,DC=com"
       },
   ...

3. To return the complete record of a specific user, include the ID of the user in the URL. The following request returns the record for Steven Carter.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/adpowershell/account/6feef4a0-b121-43dc-be68-a96703a49aba"
   {
     "_id": "6feef4a0-b121-43dc-be68-a96703a49aba",
     "postalCode": null,
     "passwordNotRequired": false,
     "cn": "Steven Carter",
     "name": "Steven Carter",
     "trustedForDelegation": false,
     "uSNChanged": "47219",
     "manager": null,
     "objectGUID": "6feef4a0-b121-43dc-be68-a96703a49aba",
     "modifyTimeStamp": "11/27/2014 3:37:16 PM",
     "employeeNumber": null,
     "sn": "Carter",
     "userAccountControl": 512,
     "passwordNeverExpires": false,
     "displayName": "Steven Carter",
     "initials": null,
     "pwdLastSet": "130615726366949784",
     "scriptPath": null,
     "badPasswordTime": "0",
     "employeeID": null,
     "badPwdCount": "0",
     "accountExpirationDate": null,
     "userPrincipalName": "steve.carter@ad0.example.com",
     "sAMAccountName": "steve.carter",
     "mail": "steven.carter@example.com",
     "logonCount": "0",
     "cannotChangePassword": false,
     "division": null,
     "streetAddress": null,
     "allowReversiblePasswordEncryption": false,
     "description": null,
     "whenChanged": "11/27/2014 3:37:16 PM",
     "title": null,
     "lastLogon": "0",
     "company": null,
     "homeDirectory": null,
     "whenCreated": "6/23/2014 2:50:48 PM",
     "givenName": "Steven",
     "telephoneNumber": "555-2518",
     "homeDrive": null,
     "uSNCreated": "20912",
     "smartcardLogonRequired": false,
     "distinguishedName": "CN=Steven Carter,CN=Users,DC=example,DC=com",
     "createTimeStamp": "6/23/2014 2:50:48 PM",
     "department": null,
     "memberOf": [
       "CN=employees,DC=example,DC=com"
     ],
     "homePhone": null
   }

4. Test whether you can authenticate as one of the users in your Active Directory. The username that you specify here can be either an ObjectGUID, UPN, sAMAccountname or CN.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/system/adpowershell/account?_action=authenticate&username=Steven+Carter&password=Passw0rd"
   {
     "_id": "6feef4a0-b121-43dc-be68-a96703a49aba"
   }

   The request returns the ObjectGUID if the authentication is successful.

5. You can return the complete record for a specific user, using the query filter syntax described in Section 7.3.4, "Constructing Queries" in the Integrator's Guide.

   The following query returns the record for the guest user.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/adpowershell/account?_queryFilter=cn+eq+guest"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 1,
     "result": [
       {
         "_id": "f2e08a5c-473f-4798-a2d5-d5cc27c862a9",
         "postalCode": null,
         "passwordNotRequired": true,
         "cn": "Guest",
         "name": "Guest",
         "trustedForDelegation": false,
         "uSNChanged": "8197",
         "manager": null,
         "objectGUID": "f2e08a5c-473f-4798-a2d5-d5cc27c862a9",
         "modifyTimeStamp": "6/9/2014 12:35:16 PM",
         "employeeNumber": null,
         "userAccountControl": 66082,
         "whenChanged": "6/9/2014 12:35:16 PM",
         "initials": null,
         "pwdLastSet": "0",
         "scriptPath": null,
         "badPasswordTime": "0",
         "employeeID": null,
         "badPwdCount": "0",
         "accountExpirationDate": null,
         "sAMAccountName": "Guest",
         "logonCount": "0",
         "cannotChangePassword": true,
         "division": null,
         "streetAddress": null,
         "allowReversiblePasswordEncryption": false,
         "description": "Built-in account for guest access to the computer/domain",
         "userPrincipalName": null,
         "title": null,
         "lastLogon": "0",
         "company": null,
         "homeDirectory": null,
         "whenCreated": "6/9/2014 12:35:16 PM",
         "givenName": null,
         "homeDrive": null,
         "uSNCreated": "8197",
         "smartcardLogonRequired": false,
         "distinguishedName": "CN=Guest,CN=Users,DC=example,DC=com",
         "createTimeStamp": "6/9/2014 12:35:16 PM",
         "department": null,
         "memberOf": [
           "CN=Guests,CN=Builtin,DC=example,DC=com"
         ],
         "homePhone": null,
         "displayName": null,
         "passwordNeverExpires": true
       }
     ]
   }

6. Test whether you are able to create a user on the Active Directory server by sending a POST request with the create action.

   The following request creates the user Jane Doe on the Active Directory server.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '{
   		 "distinguishedName" : "CN=Jane Doe,CN=Users,DC=example,DC=com",
   		 "sn" : "Doe",
   	 	"cn" : "Jane Doe",
   	 	"sAMAccountName" : "sample",
   	 	"userPrincipalName" : "janedoe@example.com",
   	 	"__ENABLE__" : true,
   	 	"__PASSWORD__" : "Passw0rd",
   	 	"telephoneNumber" : "0052-611-091"
   		}' \
    "https://localhost:8443/openidm/system/adpowershell/account?_action=create"
   {
     "_id": "42725210-8dce-4fdf-b0e0-393cf0377fdf",
     "title": null,
     "uSNCreated": "47244",
     "pwdLastSet": "130615892934093041",
     "cannotChangePassword": false,
     "telephoneNumber": "0052-611-091",
     "smartcardLogonRequired": false,
     "badPwdCount": "0",
     "department": null,
     "distinguishedName": "CN=Jane Doe,CN=Users,DC=example,DC=com",
     "badPasswordTime": "0",
     "employeeID": null,
     "cn": "Jane Doe",
     "division": null,
     "description": null,
     "userPrincipalName": "janedoe@example.com",
     "passwordNeverExpires": false,
     "company": null,
     "memberOf": [],
     "givenName": null,
     "streetAddress": null,
     "sn": "Doe",
     "initials": null,
     "logonCount": "0",
     "homeDirectory": null,
     "employeeNumber": null,
     "objectGUID": "42725210-8dce-4fdf-b0e0-393cf0377fdf",
     "manager": null,
     "lastLogon": "0",
     "trustedForDelegation": false,
     "scriptPath": null,
     "allowReversiblePasswordEncryption": false,
     "modifyTimeStamp": "11/27/2014 8:14:53 PM",
     "whenCreated": "11/27/2014 8:14:52 PM",
     "whenChanged": "11/27/2014 8:14:53 PM",
     "accountExpirationDate": null,
     "name": "Jane Doe",
     "displayName": null,
     "homeDrive": null,
     "passwordNotRequired": false,
     "createTimeStamp": "11/27/2014 8:14:52 PM",
     "uSNChanged": "47248",
     "sAMAccountName": "sample",
     "userAccountControl": 512,
     "homePhone": null,
     "postalCode": null
   }
        

7. Test whether you are able to update a user object on the Active Directory server by sending a PUT request with the complete object, and including the user ID in the URL.

   The following request updates user Jane Doe's entry, including her ID in the request. The update sends the same information that was sent in the create request, but adds an employeeNumber.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request PUT \
    --data '{
   		 "distinguishedName" : "CN=Jane Doe,CN=Users,DC=example,DC=com",
   		 "sn" : "Doe",
   	 	"cn" : "Jane Doe",
   	 	"sAMAccountName" : "sample",
   	 	"userPrincipalName" : "janedoe@example.com",
   	 	"__ENABLE__" : true,
   	 	"__PASSWORD__" : "Passw0rd",
   	 	"telephoneNumber" : "0052-611-091",
      "employeeNumber": "567893"
   		}' \
    "https://localhost:8443/openidm/system/adpowershell/account/42725210-8dce-4fdf-b0e0-393cf0377fdf"
   {
     "_id": "42725210-8dce-4fdf-b0e0-393cf0377fdf",
     "title": null,
     "uSNCreated": "47244",
     "pwdLastSet": "130615906375709689",
     "cannotChangePassword": false,
     "telephoneNumber": "0052-611-091",
     "smartcardLogonRequired": false,
     "badPwdCount": "0",
     "department": null,
     "distinguishedName": "CN=Jane Doe,CN=Users,DC=example,DC=com",
     "badPasswordTime": "0",
     "employeeID": null,
     "cn": "Jane Doe",
     "division": null,
     "description": null,
     "userPrincipalName": "janedoe@example.com",
     "passwordNeverExpires": false,
     "company": null,
     "memberOf": [],
     "givenName": null,
     "streetAddress": null,
     "sn": "Doe",
     "initials": null,
     "logonCount": "0",
     "homeDirectory": null,
     "employeeNumber": "567893",
     "objectGUID": "42725210-8dce-4fdf-b0e0-393cf0377fdf",
     "manager": null,
     "lastLogon": "0",
     "trustedForDelegation": false,
     "scriptPath": null,
     "allowReversiblePasswordEncryption": false,
     "modifyTimeStamp": "11/27/2014 8:37:17 PM",
     "whenCreated": "11/27/2014 8:14:52 PM",
     "whenChanged": "11/27/2014 8:37:17 PM",
     "accountExpirationDate": null,
     "name": "Jane Doe",
     "displayName": null,
     "homeDrive": null,
     "passwordNotRequired": false,
     "createTimeStamp": "11/27/2014 8:14:52 PM",
     "uSNChanged": "47253",
     "sAMAccountName": "sample",
     "userAccountControl": 512,
     "homePhone": null,
     "postalCode": null
   }     

8. Test whether you are able to delete a user object on the Active Directory server by sending a DELETE request with the user ID in the URL.

   The following request deletes user Jane Doe's entry.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request DELETE \
    "https://localhost:8443/openidm/system/adpowershell/account/42725210-8dce-4fdf-b0e0-393cf0377fdf"

   The response includes the complete user object that was deleted.

   You can you attempt to query the user object to confirm that it has been deleted.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/adpowershell/account/42725210-8dce-4fdf-b0e0-393cf0377fdf"
   {
     "message": "",
     "reason": "Not Found",
     "code": 404
   }

To configure an email summary, follow these steps:

1. Copy the template external.email.json file from the /path/to/openidm/samples/misc directory:

   $ cd /path/to/openidm
   $ cp samples/misc/external.email.json samples/sample5/conf
        

2. Edit the external.email.json file for outbound email, as described in Chapter 20, "Sending Email" in the Integrator's Guide.

3. Edit the reconStats.js file from the /path/to/openidm/samples/sample5/script directory. Near the start of the file, configure the OpenIDM email service to send statistics to the email addresses of your choice:

   var params = {
         //UPDATE THESE VALUES
         from : "openidm@example.com",
         to : "youremail@example.com",
         cc : "idmadmin2@example.com,idmadmin3@example.com",
         subject : "Recon stats for " + global.mappingName,
         type : "text/html"
   },
   template,
        

1. Log in to your Google Apps Admin Console (at https://www.google.com/a/domain-name) and verify that the following APIs are enabled:

   • Admin SDK API

   • Enterprise License Manager API

2. Use the OAuth 2.0 Installed Application flow to obtain a client_secrets.json file. For more information about the OAuth 2.0 Installed Application flow, see the corresponding Google documentation.

3. Download the Google Admin Directory API client library (google-api-services-admin-directory_v1-rev42-java-1.19.0.zip) and extract it to a writeable directory.

   $ unzip ~/Downloads/google-api-services-admin-directory_v1-rev42-java-1.19.0.zip -d /path/to
   Archive:  ~/Downloads/google-api-services-admin-directory_v1-rev42-java-1.19.0.zip
      creating: /path/to/admin/
    extracting: /path/to/admin/google-api-services-admin-directory_v1-rev42-1.19.0.jar
    extracting: /path/to/admin/google-api-services-admin-directory_v1-rev42-1.19.0-javadoc.jar
   ...

4. Download the Google Apps connector jar and copy it to the admin directory, created in the previous step.

   $ cp ~/Downloads/googleapps-connector-1.4.1.0.jar /path/to/admin

5. Change to the admin directory and run the following command on the client_secrets.json file that you obtained earlier in this procedure.

   $ cd admin/
   $ java -jar googleapps-connector-1.4.0.0.jar /path/to/client_secrets.json
   Please open the following address in your browser:
   https://accounts.google.com/o/oauth2/auth?
   access_type=offline
   ...

   This command opens the default browser, and loads a screen on which you authorize consent to access the Google Apps account.

   Tip

   If you have recently created your Google Apps account, it might take some time (often two hours or more) to synchronize the data required for this access request to work.

6. When you have authorized consent, the browser returns a code. Copy and paste the code into the terminal from which you ran the original command.

   Attempting to open that address in the default browser now...
   Please enter code:XXXXXXXX

   A response similar to the following is returned:

   {
       "clientId" : "5x4x3x4x0x8x-cxlx3xsxcx8xixlxmx3x0xrxgx7x6x3x.apps.googleusercontent.com",
       "clientSecret" : "0xhx9xrx8xdxqx9xDxjxUx3x",
       "refreshToken" : "1x7xmxfx_yxuxNxUxFxjxVxVxkxXx3XxHxMxYxzx5xcxI"
   }

7. Use the information in this response to edit the "configurationProperties" in the Google Apps provisioner configuration file (samples/google-connector/conf/provisioner.openicf-google.json). For example:

   "configurationProperties": {
       "domain": "example.com",
       "clientId": "5x4x3x4x0x8x-cxlx3xsxcx8xixlxmx3x0xrxgx7x6x3x.apps.googleusercontent.com",
       "clientSecret": "0xhx9xrx8xdxqx9xDxjxUx3x",
       "refreshToken": "1x7xmxfx_yxuxNxUxFxjxVxVxkxXx3XxHxMxYxzx5xcxI"
   },   

1. To run the sample, start OpenIDM with the configuration for the Google Apps Connector.

   $ cd /path/to/openidm
   $ ./startup.sh -p samples/google-connector
   Executing ./startup.sh...
   Using OPENIDM_HOME:   /path/to/openidm
   Using OPENIDM_OPTS:   -Xmx1024m -Xms1024m
   Using LOGGING_CONFIG: -Djava.util.logging.config.file=/path/to/openidm/conf/logging.properties
   Using boot properties at /path/to/openidm/samples/google-connector/conf/boot/boot.properties
   OpenIDM version "3.1.0" (revision: 0) null null
   -> OpenIDM ready
        

2. To verify the connector configuration, check the status of the Google Apps connector as follows:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/system/google?_action=test"
   {
       "name":"google",
       "enabled":true,
       "config":"config/provisioner.openicf/google",
       "connectorRef": {
           "connectorName":"org.forgerock.openicf.connectors.googleapps.GoogleAppsConnector",
           "bundleName":"org.forgerock.openicf.connectors.googleapps-connector",
           "bundleVersion":"[1.4.0.0,2.0.0.0)"
       },
       "ok":true
   }

3. To test that the connector is working, create, update, and read a user and group entry on the Google resource, over REST.

   Note

   When creating resources for Google, note that the equals (=) character cannot be used in any attribute value.

   The following command creates an entry for user Sam Carter:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '{
     "__NAME__": "samcarter@example.com",
     "__PASSWORD__"  : "password",
     "givenName" : "Sam",
     "familyName": "Carter",
     "agreedToTerms": true,
     "changePasswordAtNextLogin" : false
    }' \
    "https://localhost:8443/openidm/system/google/__ACCOUNT__?_action=create" \
   
   {
       "phones":null,
       "givenName":"Sam",
       "familyName":"Carter",
       "thumbnailPhotoUrl":null,
       "addresses":null,
       "__NAME__":"samcarter@example.com",
       "changePasswordAtNextLogin":false,
       "suspensionReason":null,
       "aliases":null,
       "customerId":"Cwev45or",
       "isDelegatedAdmin":false,
       "lastLoginTime":["1970-01-01T00:00:00.000Z"],
       "agreedToTerms":true,
       "deletionTime":null,
       "isAdmin":false,
       "creationTime":["2014-09-23T18:54:19.000Z"],
       "ims":null,
       "organizations":null,
       "ipWhitelisted":false,
       "fullName":"Sam Carter",
       "includeInGlobalAddressList":true,
       "isMailboxSetup":false,
       "externalIds":null,
       "suspended":false,
       "nonEditableAliases":null,
       "orgUnitPath":"/",
       "relations":null,
       "emails": [
           {
               "address":"samcarter@example.com",
               "primary":true
           }
       ],
       "_id":"101643010677712061243",
       "_rev":"\"SHoRIPAZisvsSqsLJr3m3XS9Uw4/RfZOwrjqrpRsO6PCGNfEp2H00Ds\""
   }

4. Update the user's phone number by sending a PUT request with the updated data, and specifying the user ID in the request, for example:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request PUT \
    --data '{
     "__NAME__": "samcarter@example.com",
     "__PASSWORD__"  : "password",
     "givenName" : "Sam",
     "familyName": "Carter",
     "agreedToTerms": true,
     "changePasswordAtNextLogin" : false
     "phones" :
      [
       {
        "value": "1234567890",
        "type": "home"
       },
       {
        "value": "0987654321",
        "type":"work"
       }
      ]
     }' \
    "https://localhost:8443/openidm/system/google/__ACCOUNT__/101643010677712061243"

   The response returns the complete user object, with the updated phone numbers.

5. Read the user entry from the Google resource:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "If-None-Match" : "*" \
    --request GET \
    "https://localhost:8443/openidm/system/google/__ACCOUNT__/101643010677712061243"
   {
       "phones":
           [
               {"value":"1234567890","type":"home"},
               {"value":"0987654321","type":"work"}
           ],
       "givenName":"Sam",
       "familyName":"Carter",
   ...
       "_id":"101643010677712061243",
       "_rev":"\"SHoRIPAZisvsSqsLJr3m3XS9Uw4/RfZOwrjqrpRsO6PCGNfEp2H00Ds\""
   }     

6. Create a group entry on the Google resource.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    --data '{
     "__NAME__": "testGroup@example.com",
     "__DESCRIPTION__": "Group used for google-connector sample.",
     "name": "TestGroup"
    }' \
    "https://localhost:8443/openidm/system/google/__GROUP__?_action=create"
    
   {
    "__DESCRIPTION__": "Group used for google-connector sample.",
    "directMembersCount": 0,
    "nonEditableAliases": null,
    "aliases": null,
    "adminCreated": true,
    "name": "TestGroup",
    "__NAME__": "testGroup@example.com",
    "_id": "03oy7u291s3qw1i",
    "_rev": "\"SHoRIPAZisvsSqsLJr3m3XS9Uw4/8JZsrHGxtdaH4sF8vgzLiPmPqFs\""
   }

7. Add the user Sam Carter, that you created previously, to the test group. Include the _id that was generated in the user creation step in the request URL.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request PUT \
    --data '{
     "groupKey" : "03oy7u291s3qw1i",
     "role": "MEMBER",
     "__NAME__": "samcarter@example.com",
     "email": "samcarter@example.com",
     "type": "MEMBER"
    }' \
    "https://localhost:8443/openidm/system/google/Member/101643010677712061243"
    
   {
       "role": "MEMBER",
       "type": "USER",
       "email": "samcarter@example.com",
       "__NAME__": "03oy7u291s3qw1i/samcarter@example.com",
       "groupKey": "109384837631312225274",
       "_id": "014ykbeg40r6x06/samcarter@example.com",
       "_rev": "\"SHoRIPAZisvsSqsLJr3m3XS9Uw4/GiZLiMKb3U62M58IabSzPKAVIOE\""
   }

8. Read the group entry by specifying the group _id in the request URL. Notice that the group has one member ("directMembersCount": 1).

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/system/google/__GROUP__/03oy7u291s3qw1i"
    
   {
       "__DESCRIPTION__": "Group used for google-connector sample.",
       "directMembersCount": 1,
       "nonEditableAliases": [
           "googleAppsTestGroup@example.com.test-google-a.com"
       ],
       "aliases": null,
       "adminCreated": true,
       "name": "TestGroup",
       "__NAME__": "testGroup@example.com",
       "_id": "03oy7u291s3qw1i",
       "_rev": "\"SHoRIPAZisvsSqsLJr3m3XS9Uw4/WcZC54etzuPtruE7uByf9NQ82Ow\""
   }

9. Delete the group entry.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json"
    --request DELETE \
    "https://localhost:8443/openidm/system/google/__GROUP__/03oy7u291s3qw1i"
    
   {
       "_id": "03oy7u291s3qw1i"
   }

   The delete request returns the group ID.

10. Delete the user Sam Carter, to return the Google system to its original state.

    $ curl \
     --cacert self-signed.crt \
     --header "X-OpenIDM-Username: openidm-admin" \
     --header "X-OpenIDM-Password: openidm-admin" \
     --request DELETE \
     "https://localhost:8443/openidm/system/google/__ACCOUNT__/101643010677712061243" 
    {
        "_id":"101643010677712061243"
    }

To set up a Connected App for OpenIDM, follow these steps:

1. Log in to salesforce.com with your Salesforce credentials.

2. Click Setup in the top right corner.

3. In the left hand menu, under Build, expand the Create item and click Apps.

4. On the right hand panel, scroll down to Connected Apps and click New.

5. In the New Connected App panel, enter the following Basic Information:

   • Connected App Name. Enter a name that you will recognize as the OpenIDM App, for example, OpenIDM.

   • API Name. This field defaults to the Connected App Name, but you can change it. Note that the Application API Name can only contain underscores and alphanumeric characters. The name must be unique, begin with a letter, not include spaces, not end with an underscore, and not contain two consecutive underscores.

   • Contact Email. Enter the email address of the person responsible for this Connected App within your organization.

6. Select Enable OAuth Settings and enter the following information:

   • Callback URL. Enter the OpenIDM URL, to which the requested OAuth token will be sent, for example https://localhost:8443/admin/oauth.html.

   • Selected OAuth Scopes. Click the Add button to add the following Available Auth Scopes to the Selected OAuth Scopes column:

     • Access and manage your data

     • Access your basic information

     • Perform requests on your behalf at any time

     

     You can leave the remaining fields blank.

7. Click Save to create the new Connected App.

8. The next window displays your new Connected App.

   Under the API (Enable OAuth Settings) item, the Consumer Key and a link to the Consumer Secret are displayed.

   Click the link to reveal the Consumer Secret.

   

   OpenIDM requires the Consumer Key and Secret to obtain an access token and a refresh token for access to salesforce.com.

   Copy and paste both the key and the secret into a file for use when you set up the sample.

9. To demonstrate the reconciliation of users from Salesforce to OpenIDM, your Salesforce organization should contain at least a few users. Add these users now if your Salesforce organization is empty.

1. Log in to the Admin UI at the URL https://localhost:8443/admin as the default administrative user (openidm-admin) with password openidm-admin.

   The first time you log into the Admin UI, you are prompted to change your password. If you do not want to change your password at this time, simply click X to close this window, and continue with the sample.

   The Resources tab shows the Salesforce connector, which is currently disabled.

   

2. Enable the Salesforce connector by completing the authentication details as follows. You will need the Consumer Key and Consumer Secret that you obtained in the previous section.

   • Click on the Salesforce connector to open the Edit Connector dialog.

   • Select True from the Enabled list.

   • Select Salesforce Connector from the Connector Type list.

   • Under Basic Connector Details select the Sandbox URL (for the purposes of testing the sample) and enter the Connector Key and Secret that you obtained in the previous section.

   • You can leave the default LiveSync details for now. Click Update to update the connector configuration.

     

   • On the permission request screen click Allow, to enable OpenIDM to access your Salesforce Connected App.

     Note

     In the current OpenIDM release, an issue is occasionally seen where the system appears to time out while retrieving the refresh token from Salesforce, at this stage. If this happens, refresh your browser and attempt the connector setup again.

     On the Resources tab, your Salesforce Connector should now be Active.

     

3. To test the reconciliation process, select the Mappings tab.

   This tab shows two configured mappings, one from Salesforce to the OpenIDM repository (managed/user) and one from the OpenIDM repository to Salesforce.

   

4. Click anywhere on the first mapping and click Reconcile Now.

   

   The reconciliation operation creates the users that were present in your Salesforce organization in the OpenIDM repository.

5. Retrieve the users in the repository by clicking the User View link at the top right of the Admin UI.

   This link opens the User View UI. If you did not change your password in the first step, you are prompted to change your password again. You can bypass this by simply clicking X to close the password prompt window.

6. Select the Users tab.

   

   The users from the Salesforce organization have been reconciled to the OpenIDM repository. If the reconciliation was successful, the list of users displayed here should reflect what was in your Salesforce organization.

7. To retrieve the details of a specific user, click that username on the Users tab.

   The following image shows the details of user bjensen. Note the Linked Systems panel at the bottom of the image. This panel shows the corresponding user record in Salesforce.

   

8. To test the second mapping (from OpenIDM to Salesforce), update any user in the OpenIDM repository. For example, update Babs Jensen's username.

9. By default, implicit synchronization is enabled for mappings from the managed/user repository to any external resource. This means that when you update a managed object, any mappings defined in the sync.json file that have the managed object as the source are automatically executed to update the target system. For more information, see Section 12.3.2, "Synchronization Mappings File" in the Integrator's Guide.

   To test that the implicit synchronization has been successful, look at Babs Jensen's record in the User View UI. At the bottom of the user profile, the Linked Systems panel indicates Babs Jensen's record in the Salesforce data store. Note the changed Username.

   Alternatively, check the updated user record in Salesforce.

Before you start, you will need the Consumer Key and Consumer Secret that you obtained in the previous section.

1. Obtain the refresh token from salesforce.com by pointing your browser to the following URL. Substitute your Consumer Key for CLIENT_ID. If OpenIDM is not running on the localhost, substitute the appropriate hostname and port number in the value of the redirect_uri parameter.

   https://login.salesforce.com/services/oauth2/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=https://localhost:8443/admin/oauth.html&scope=id%20api%20refresh_token

2. You are redirected to Salesforce, and prompted to give this application access to your Salesforce account. When you have given consent, you should receive a response URL that looks similar to the following:

   https://localhost:8443/admin/index.html#connectors/edit//&code=aPrxJZTK7Rs03PU634VK8Jn9o_U3ZY1ERxM7IiklFzbmVpZ1TTJlU1TiETXKhNHqpr4SlyCkpg%3D%3D

   The &code part of this URL is an authorization code, that you need for the following step.

   Caution

   Note that this authorization code expires after 10 minutes. If you do not complete the OAuth flow within that time, you will need to start this process again.

3. Copy the authorization code from the response URL and use it as the value of the "code" parameter in the following REST call. You will also need to supply your Consumer Key and Consumer Secret in this call.

   $  curl \
    --verbose \
    --data "grant_type=authorization_code" \
    --data "client_id=consumer-key" \
    --data "client_secret=consumer-secret" \
    --data "redirect_uri=https://localhost:8443/admin/oauth.html" \
    --data "code=access-token-code" \
    "https://login.salesforce.com/services/oauth2/token"
   {
     "access_token": "00DS0000003K4fU!AQMAQOzEU.8tCjg8Wk79yKPKCtrtaszX5jrHtoT4NBpJ8x2NFZGjg3PNuc0TWq0EgiGS_mVkfg5f4pVN5uhXbmAx6hRyk80Z",
     "signature": "2uREX1lseXdg3Vng/2+Hrlo/KHOWYoim+poj74wKFtw=",
     "refresh_token": "5Aep861KIwKdekr90I4iHdtDgWwRoG7O_6uHrgJ.yVtMS0UaGxRqE6WFM77W7wCV4muVMgdqKjuWI2i5S6sjN2X",
     "token_type": "Bearer",
     "instance_url": "https://example-com.cs1.my.salesforce.com",
     "scope": "id api refresh_token",
     "issued_at": "1417182949781",
     "id": "https://login.salesforce.com/id/00DS0000003K4fUMAS/00530000009hWLcAAM"
   }

   The output includes an access_token and a refresh_token. You will need the refresh_token in the following step.

4. Edit the configurationProperties in your Salesforce connector configuration file (openidm/samples/salesforce-connector/conf/provisioner.salesforce-salesforce.json) to include your Consumer Key (clientID), Consumer Secret (clientSecret), and refresh token.

   In addition, set the "instanceUrl" to the value returned in the previous step, and set the "enabled" property to true.

   The relevant excerpts of the provisioner.salesforce-salesforce.json file are as follows:

   {
       "name" : "salesforce",
       "enabled" : true,
       "connectorRef" : {
   ...
       "configurationProperties" : {
           "connectTimeout" : 120000,
           "loginUrl" : null,
           "idleCheckInterval" : 10000,
           "refreshToken" : "5Aep861KIwKdekr90I4iHdtDgWwRoG7O_6uHrgJ.yVtMS0UaGxRqE6WFM77W7wCV4muVMgdqKjuWI2i5S6sjN2X",
           "clientSecret" : "4850xxxxxxxxxxxxx425",
           "clientId" : "3MVG98dostKihXN7Is8Q0g5q1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxPdB5f5ATwmaMuWxl",
           "instanceUrl" : "https://example-com.cs1.my.salesforce.com",
           "version" : 29
       }
   ... 

5. Check that your connector configuration is correct by testing the status of the connector, over REST.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/system?_action=test"
   [
     {
       "ok": true,
       "connectorRef": {
         "bundleVersion": "2.0.29.1a",
         "systemType": "provisioner.salesforce",
         "displayName": "Salesforce Connector",
         "bundleName": "org.forgerock.openidm.salesforce",
         "connectorName": "org.forgerock.openidm.salesforce.Salesforce"
       },
       "objectTypes": [
         "User",
         "PermissionSet",
         "PermissionSetAssignment",
         "Profile",
         "PermissionSetLicenseAssign",
         "Organization",
         "PermissionSetLicense",
         "Group",
         "GroupMember"
       ],
       "config": "config/provisioner.salesforce/salesforce",
       "enabled": true,
       "name": "salesforce"
     }
   ]
        

The mapping configuration file (sync.json) for this sample includes two mappings, sourceSalesforceUser_managedUser, which synchronizes users from the Salesforce with the OpenIDM repository, and managedUser_sourceSalesforceUser, which synchronizes changes from the OpenIDM repository to Salesforce.

1. Reconcile the repository over the REST interface by running the following command:

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --header "Content-Type: application/json" \
    --request POST \
    "https://localhost:8443/openidm/recon?_action=recon&mapping=sourceSalesforceUser_managedUser&waitForCompletion=true"
   {
     "state": "SUCCESS",
     "_id": "8a6281ef-6faf-43dd-af5c-3a842b38c468"
   }

   The reconciliation operation returns a reconciliation run ID and the status of the operation. Reconciliation creates user objects from LDAP in the OpenIDM repository, assigning the new objects random unique IDs.

2. View the recon entry over REST for an indication of the actions that were taken on the OpenIDM repository.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/recon/8a6281ef-6faf-43dd-af5c-3a842b38c468"
   {
     "duration": 6447,
     "ended": "2014-11-28T15:01:38.399Z",
     "started": "2014-11-28T15:01:31.952Z",
     "parameters": {
       "null": false,
       "boolean": false,
       "number": false,
       "list": false,
       "object": {
         "targetQuery": {
           "_queryId": "query-all-ids",
           "resourceName": "managed/user"
         },
         "sourceQuery": {
           "_queryId": "query-all-ids",
           "resourceName": "system/salesforce/User"
         }
       },
       "pointer": {
         "empty": true
       },
       "transformers": [],
       "set": false,
       "map": true,
       "string": false,
       "collection": false,
       "wrappedObject": {
         "targetQuery": {
           "resourceName": "managed/user",
           "_queryId": "query-all-ids"
         },
         "sourceQuery": {
           "_queryId": "query-all-ids",
           "resourceName": "system/salesforce/User"
         }
       }
     },
     "_id": "8a6281ef-6faf-43dd-af5c-3a842b38c468",
     "mapping": "sourceSalesforceUser_managedUser",
     "state": "SUCCESS",
     "stage": "COMPLETED_SUCCESS",
     "stageDescription": "reconciliation completed.",
     "progress": {
       "links": {
         "created": 8,
         "existing": {
           "total": "0",
           "processed": 0
         }
       },
       "target": {
         "created": 8,
         "existing": {
           "total": "0",
           "processed": 0
         }
       },
       "source": {
         "existing": {
           "total": "9",
           "processed": 9
         }
       }
     },
     "situationSummary": {
       "FOUND_ALREADY_LINKED": 0,
       "UNASSIGNED": 0,
       "TARGET_IGNORED": 0,
       "SOURCE_IGNORED": 0,
       "MISSING": 0,
       "FOUND": 0,
       "AMBIGUOUS": 0,
       "UNQUALIFIED": 0,
       "CONFIRMED": 0,
       "SOURCE_MISSING": 0,
       "ABSENT": 9
     },
     "statusSummary": {
       "SUCCESS": 8,
       "FAILURE": 1
     }
   }

   The output shows that eight entries were created on the target (managed/user).

3. You can display those users by querying the IDs in the managed/user repository.

   $ curl \
    --cacert self-signed.crt \
    --header "X-OpenIDM-Username: openidm-admin" \
    --header "X-OpenIDM-Password: openidm-admin" \
    --request GET \
    "https://localhost:8443/openidm/managed/user?_queryId=query-all-ids"
   {
     "remainingPagedResults": -1,
     "pagedResultsCookie": null,
     "resultCount": 8,
     "result": [
       {
         "_rev": "0",
         "_id": "f15322f2-5873-4e5f-a4e5-2d4bc03dd190"
       },
       {
         "_rev": "0",
         "_id": "85879c60-afa1-4425-8c7a-5cccbbaff587"
       },
       {
         "_rev": "0",
         "_id": "ed3fe655-29a6-4016-b6bc-4b2356911fd1"
       },
       {
         "_rev": "0",
         "_id": "34678464-c080-41b1-8da6-d5fde9d35aeb"
       },
       {
         "_rev": "0",
         "_id": "02d5da29-8349-4f35-affc-5f6c331307ef"
       },
       {
         "_rev": "0",
         "_id": "f91d6fce-bf27-4379-9411-fd626f8a9528"
       },
       {
         "_rev": "0",
         "_id": "6ace9220-59e7-4d97-8683-e03362a9150c"
       },
       {
         "_rev": "0",
         "_id": "56863eea-35d7-4aeb-a017-74ef28fd3116"
       }
     ]