SOAP/REST API
Both Internal and External users can be provisioned by using SOAP and REST API on the User object. While creating External users it is required to associate a valid
contact and
account to the user and the account must be owned by a Salesforce user that has
role.
To create or update a User record, you must have the “Manage Internal Users” permission. If the user is a Customer Portal user, you must have the “Edit Self-Service Users” permission. If the user is a partner portal user, you must have the “Manage External Users” permission.
Salesforce provides the following methods to provision a new user:
SOAP API
- create(sObject[] sObjects) lets your create Internal users.
REST API
- POST user data to the sobject user endpoint
APEX
- createPortalUser(user, accountId, password) lets you create an External user to a Customer or Partner Account.
- createPersonAccountPortalUser(user, ownerId, password) lets you create an external user associated to a Person Account.
EXTERNAL USERS PROVISIONING
We have to follow below steps to provision an external user
- Create a contact record and associate it to an account
- Create a user record from the contact and assign a user profile that has access to the communities
The associated account decides the type of user that can be provisioned. If the account type is person account of customer account, customer users can be provisioned and if the account type is partner then both partner and customer users can be provisioned.
In order to create a partner user, we need to initially enable the account as partner account. It can be done by setting the isPartner value to true on Account record.
External users can be provisioned on the accounts that are owned by a Internal user who has a role associated to them. External users can be created by
Salesforce users with
Manage External Users permission or other
External users with
Delegated External User Administrator permission.
Provisioning of External users can be done in number of ways
- Manual Provisioning
- To manually provision an external user as an administrator or delegated administrator for non-partner or person account
- Go to Contact detail page
- Click Manage External User
- Click Enable Customer User
- Select a customer profile (Ensure that this profile is already added to community)
- Click Save to create user.
- If Welcome Email is enabled for community, an email with username and a link to reset password is sent to the user. If the selected profile is associated with multiple communities, multiple emails will be triggered but only first email contains reset password link.
- To manually provision an External user as an administrator or delegated administrator for a partner Account
- Go to Contact detail page
- Click Manage External User
- Click Enable Partner User
- On User detail page select Role (you may have up to three roles available for each partner account depending on the Community Settings. The Partner Role Hierarchy reports to Account Owners role)
- Self Registration
- For B2C communities, it makes sense to enable self registration to let visitors self register to the community
- The flow is as follows
- Visitor clicks or gets redirected to Self Registration page
- Visitor fills in a form and submits his information
- Salesforce creates Contact and User Records
- If a user profile is added to community, user gets instant access to Community
- Setup
- Enable self registration in Community
- Go to Community Workspace and select Administration
- Click Login & Registration
- Select Allow external users to self-register under Registration Page Configuration section
- Select Registration page type, you can select
- default salesforce provided page,
- Configurable Self Registration page that allows you to select some fields that you wanted to display on the Registration page
- Community Builder page, the custom page that you developed
- or a Visualforce page that you designed.
- Optionally, select Profile and Account that you want to assign to the created user.
- Customize Self-registration code
- Edit the CommunitiesSelfRegController or any other Controller that you are using in case you selected Visualforce in earlier step
- Here you can logically assign Account and Profile (to override the default profile and Account that you selected in earlier step
- In case of B2B customers (if using this for partners), assign a role.
- Customize Self-registration page
- Salesforce provides CommunitiesSelfReg page that can be customized and branded as needed
- API Provisioning
- External users can be provisioned by using SOAP and REST API on the User object. While creating External users it is required to associate a valid contact and account to the user and the account must be owned by a Salesforce user that has role
- Salesforce provides the following methods to provision a new user:
- SOAP API
- create(sObject[] sObjects) lets your create users.
- REST API
- POST user data to the sobject user endpoint
- APEX
- createPortalUser(user, accountId, password) lets you create an External user to a Customer or Partner Account.
- createPersonAccountPortalUser(user, ownerId, password) lets you create an external user associated to a Person Account.
- Social Sign-On Provisioning
- It enables users to authenticate from a range of identity providers that includes Facebook, Janrain, Google, Microsoft, LinkedIn, Twitter, Github another Salesforce account and any open ID connect provider
- Setup
- Create and Test Authentication Provider
- Select Auth. Providers from Setup → Home
- Click New and select the provider type
- Fill the Auth provider metadata
- Name the Provider,
- click Automatically create a registration handler template to enable salesforce create a handler for you
- Select a user for Execute Registration As.
- Choose an Icon URL
- Copy and Paste Test-Only Initialization URL in browser, if it works you get Facebook login page. After authorizing You’re redirected to Salesforce, where you see the XML information that Facebook sent us.
<user>
<full_name>Jayaprakash Narayan</full_name>
<provider>Facebook</provider>
<org_id>00Dxxxxxxxxxx</org_id>
<last_name>Narayan</last_name>
<id>123157175259593024</id>
<portal_id>000000000000000</portal_id>
<first_name>Jayaprakash</first_name>
<email>xyz@abc.com</email>
</user>
-
-
- Enable Social Sign-on for Communities
- From community workspace, select Administration
- Select Login & Registration
- Select the Auth Provider that you create in last step under Login Page Setup
- JIT Provisioning over SAML
- Overview
- With Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you have a customer that needs access to your support Community, you don’t need to manually create the user in Salesforce. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort with on-boarding the account. This greatly simplifies the integration work required in scenarios where users need to be dynamically provisioned, by combining the provisioning and single sign-on processes into a single message.
- Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion attribute statement. You can both create and modify users, contacts, and accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled.
- Benefits
- Reduces Administrative costs
- Increased User Adoption
- Increased Security
- Setup
- Go to Setup → Single Sign-On Settings
- Click Edit your enabled SAML Single Sign-On Settings
- Select User Provisioning Enabled checkbox under Just In-time User Provisioning.
- Requirements
- JIT Provisioning requires creation of SAML Assertion. When constructing SAML assertion for provisioning it is simple required to add a series of attributes to normal Single Sign-On message.
- SAML subject: It’s required that you use Federation ID as your SAML Subject’s NameID. This is a string of 512 characters or less that is used as an external id for your users. It must be unique across the org, and it is case-sensitive. It does not have to have any specific format (in particular, it does not need to be in the form of an email address).
- Account Attributes (For External Users): AccountName, AccountNumber, Account Owner. Other fields may include AnnualRevenue, Ticker Symbol and custom fields. Account Names and AccountNumbers must be unique.
- Contact Attributes (For External Users): LastName and Email are required attributes. Additionally we can add FirstName and other custom fields.
- User Attributes: Lastname, Email, UserName, ProfileId, PortalRole (for Partner user).
- JIT provisioning is not supported for Person Accounts.
- Flow of Actions
- As documented in this knowledge article, when provisioning over SAML, Salesforce first attempts to match the Federated ID to the Federation ID field of a User record.
- If a User record with a matching Federation ID is found, the user is authenticated, and all of the editable User fields specified in the assertion are updated with the values assigned. In addition, some of the Contact and Account fields can be updated (e.g., the Account.TickerSymbol field can be updated; Contact.LastName and Contact.FirstName can be updated).
- If no matching User record is found, Salesforce searches all Contacts for a match based on Email. If a matching Contact is found, Salesforce creates the User record and updates the Contact fields specified.
- If no matching Contact record is found, Salesforce searches for a matching Account by Account.Name or Account.AccountNumber.
- If a matching Account record is found, Salesforce creates a new Contact on that Account with the last name and email address specified and then creates a User record with the specified fields (1).
- If no matching Account is found, then Salesforce creates the Account with the specified Name, AccountNumber, and Owner; creates the Contact with the information specified (again, the Contact.Email attribute must be unique across all Contacts on all Accounts); and creates the User record (2).
- (1) The Contact.Email attribute value must be unique across all Contact records on all Account records, or provisioning will fail.
- (2) The specified Account Owner must have a Role or provisioning will fail.
- Mass user Provisioning
- Data loader or Workbench
- Pre-Load activities
- Set up your Community accounts (Partner or Customer).
- Add contacts to the accounts.
- Create the Community Role that your Users will be using (for role-based partner users only).
- Create a .csv import file for importing users with the below fields
- RoleId (optional, otherwise default to user role for partner users)
- FirstName
- LastName
- ContactId (use the contact id of previously created contact)
- ProfileId
- Username
- Email
- Alias
- TimeZoneSidKey, LocaleSidKey (can be found by extracting a user from System)
- EmailEncodingKey
- LanguageLocaleKey
- Export the contacts for which you want to create users.
- Add contact info to the .csv import file; complete empty fields.
- Load Process
- Import the .csv file through Data Loader or Workbench
- Bulk User Provisioning using
- createPortalUser(user, accountId, password) lets you create an External user to a Customer or Partner Account.
- createPersonAccountPortalUser(user, ownerId, password) lets you create an external user associated to a Person Account.
- A Salesforce user can be the owner of up to 50,000 person account portal users. This includes person account users with Customer Community Plus, Customer Portal, and other role-based portal licenses. Person account users with high volume portal licenses such as High Volume Customer Portal or Customer Community don’t count against this limit. Users with partner portal or Partner Community licenses can’t be person accounts users, so this limit doesn’t apply.
- Identity Connect
- Overview
- Most of the Enterprise customers might already be using Active Directory for managing their users. While SOAP/REST API can be used to provision these users, Salesforce provides a way to Synchronize these users using Identity Connect.
- Identity Connect is a Salesforce Identity product that helps Salesforce admins apply all the data collected in Active Directory (AD) to automate Salesforce user management. It syncs changes in AD within seconds.
- With Identity Connect, you can manage Salesforce users by relying on the data already entered in AD. Identity Connect constantly monitors AD and updates Salesforce when changes in AD occur. Syncing can occur in near real time, on a regular schedule, or both.
- Data transfer is in one direction and AD is the source of truth. Identity Connect never changes information that’s stored in AD.
- You can set up single sign-on (SSO) with Identity Connect so that users can access Salesforce with their AD credentials.
- Identity connect is an add-on license
- Benefits
- Keeps your employees happy by providing access to them without any delays
- Provides security as once the user is off-boarded and changes occur at AD, they can be reflected back to Salesforce within no time.
- Reduces IT concerns
- Setup
- Identity Connect requires My Domain.
- Decide how Identity Connect fits in with your network infrastructure.
- Install Identity Connect on one or more computers.
- Configure the connection between AD and Identity Connect.
- In Salesforce, create a connected app to connect Identity Connect to Salesforce.
- Determine the best way to map your data between AD and Salesforce.
- Configure a synchronization schedule.
- Run pre-sync reconciliation report. Analyze, link, and clean up user data.
- Run sync then post-sync reports.
- Configure SSO (optional).
- Deployment Considerations
- Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce. Identity Connect’s server runs within the corporate network and communicates with the AD server over LDAP(S). It communicates with in-the-cloud Salesforce over HTTPS. Work with your networking engineer to ensure that these paths are open so that Identity Connect can connect to both AD and Salesforce.
- Though dedicated server is not required for Identity Connect ensure that adequate resources are available on the Shared Server.
- The demilitarized zone (DMZ) is a subnetwork that separates your internal network from other untrusted networks, like the Internet. But it’s still on-premises, within the corporate network. Instead of installing Identity Connect behind the firewall, you can install it in the DMZ.
- When using Identity Connect for SSO, put Identity Connect in the DMZ if:
- Your users log in to Salesforce from outside your trusted network. This way, your external users can access the Identity Connect login page without having to use a VPN.
- You want users to log in to Salesforce from a mobile device. Otherwise, your users must be on a mobile VPN.
- Identity Connect is designed to work with multiple Salesforce orgs. You can set up Identity Connect to manage all these orgs simultaneously.
- Identity Connect is designed to work with a single AD domain. But you can still use Identity Connect with multiple domains using a global catalog. A global catalog is a special domain controller that aggregates all user and group information from all AD domains into a central repository. (A domain controller is a computer on which AD is installed.)
- For user provisioning, Identity Connect connects with Salesforce over REST APIs to validate and update user settings so keep an eye on REST API Limits.
- You can redirect users to Identity Connect directly from your My Domain configuration page.
- Disable Salesforce passwords to ensure that your users log in to Salesforce with their AD credentials. Without a Salesforce password, users can never bypass Identity Connect when logging in.
- Having Identity Connect integrated with IWA (Integrated Windows Authentication) saves users an extra log in. Once users log in to their computers with their AD username and password, Identity Connect recognizes the user and doesn’t prompt them to log in to Salesforce. If your company has experience with IWA or an Identity partner with IWA experience, consider this feature
USER PROVISIONING FOR CONNECTED APPS
- Overview
- You can use a connected app to link your users with a third-party app. User provisioning for a connected app simplifies account creation and links your Salesforce users’ accounts to their third-party accounts. After the accounts are linked, you can configure the App Launcher to display the connected app as a tile. With a single click, users get instant access to the third-party app.
- User provisioning applies only to users with a profile or permission set that grants them access to the connected app.
- Salesforce provides a wizard to guide you through the user provisioning settings for each connected app. You can also run reports to see who has access to specific third-party apps. These reports give you a centralized view of all user accounts across all connected apps.
- Considerations
- With user provisioning, you can create a user account for a service provider. However, the service provider must manage any additional roles or permissions for the user.
- Run the User Provisioning wizard each time you want to collect and analyze users in the third-party system. You can’t configure an interval for an automatic collection and analysis.
- Set up
- Before using the guided wizard the below are required
- Connected app for third party service to provision
- Named Credentials
- A flow to manage provisioning requests to the third-party service or app
REFERENCES
Post Views:
2,113
