The mechanism that is available for required operation data caching required is the <operation-data> element. Because you might need to provision the SecretStore account from either an <add> or <modify-password> command, a logical place to implement the non-static data caching policy is in the Subscriber Command Transformation policy. The following example shows a typical SecretStore Provisioning element:
<operation-data> <nss-sync-data> <nss-target-user-dn> cn=GLCANYON,ou=finance,o=Testco Financials </nss-target-user-dn> <nss-app-username>GCANYON</nss-app-username> <password><!-- content suppressed --></password> <nss-passphrase-answer>50024222</nss-passphrase-answer> </nss-sync-data> </operation-data>
In the sample Finance department scenario from Figure 5-1, Credential Provisioning with SecretStore, the following values are needed to populate the operation data payload:
The <nss-target-user-dn> element is populated with the value of the DirXML-ADContext attribute from the Identity Vault, which was set by the eDirectory driver. To ensure that the GroupWise driver is notified when the value is set by the eDirectory driver, make sure you add DirXML-ADContext to the Subscriber filter as a notify attribute.
The <nss-app-username> element is populated by the value of the CN attribute in the Identity Vault.
The password element is populated with the value of the <password> element in the <add> or <modify-password> command.