The following example illustrates the provisioning of a new user account to Salesforce using the SAML2/Account Management application for Salesforce.
You create an Active Directory user account in your Access Manager user store. The user is not yet a member of any group.
In the Applications section of Access Manager, you import the SAML/Account Management connector for Salesforce. You set the Attribute mapping as follows:
Remote Attribute : Salesforce ID
System Attribute: Ldap Attribute:mail
You enable Account Management and configure the connector settings, along with an LDAP user store and one or more mapped groups. You click Save.
SaaS Account Management creates a configuration file in the Psearchservice, and it begins polling the LDAP user stores. Because the user is not yet a member of any mapped group, the user is not provisioned and is not able to single sign-on to Salesforce yet.
In your Active Directory user store, you add the same user to the mapped group that you specified in step 3.
SAM polls the user store at the polling interval you set for the application, and sees that the user account is now a member of the mapped group.
SAM creates a new user account in Salesforce and the user is able to single sign-on to Salesforce by clicking the Salesforce appmark on the Access Manager user portal page.
SAM creates events showing these updates, and records details of the user account created in Salesforce.
You modify the user’s last name in your Active Directory user store.
SAM polls the user store again, and sees the update to that user account.
The change to the user’s name is reflected in the Salesforce user account, and single sign-on continues to work as expected.
In your Active Directory user store, you remove the user from the mapped group.
SAM polls the user store again, and sees that the user account is no longer a member of the mapped group.
SAM changes the user’s status at Salesforce from Active to Not Active, and the user is no longer able to use single sign-on to access Salesforce.
You add the user back into the mapped group.
SAM polls the user store again, and sees that the user account is again a member of the mapped group.
SAM changes the user’s status at Salesforce from Not Active back to Active, and the user is again able to use single sign-on to access Salesforce. No modifications to the user’s account settings occurred.
In your Active Directory user store, you move the user account out of the configured search context, (but the user is still a member of the mapped group).
SAM polls the user store again, and sees that the user account is no longer in the search context.
The user’s status at Salesforce changes from Active to Not Active, and the user is not able to single sign-on to Salesforce. (Actually, the user cannot log in to Access Manager either, since the user is out of the search context.)
In your Active Directory user store, you move the user account back into the configured search context.
SAM polls the user store again, and sees that the user account is again in the search context (and still in the mapped group).
The user’s status at Salesforce changes from Not Active to Active, and the user is able to single sign-on to Salesforce again.