The connector for Google Apps, the connector for Salesforce, the connector for ServiceNow, and the connector for Microsoft Office 365 support both account provisioning and single sign-on. These connectors are delivered with the appliance. You can use these connectors if you have a CloudAccess license as well as an account with the destination service.
The connectors that support SSO and provisioning can provision accounts for users in your corporate identity sources for Active Directory, eDirectory, and JDBC. For CloudAccess to provision user accounts to the SaaS applications, each user account in the identity source must contain the attributes listed. If you are using an LDAP identity source, there are specific attributes that must be populated on the user accounts. If you are using a JDBC database, there are certain columns of information that must be populated. The information for each identity source is different. For more information about identity source requirements for provisioning, see Configuring LDAP and JDBC Identity Sources
in the CloudAccess Installation and Configuration Guide.
By default, the connectors use the user name when provisioning users to the SaaS applications. However, you can change the naming policy to match accounts that might already exist in the SaaS applications, and let CloudAccess use them for management and providing SSO. For more information, see Section 2.4.6, Understanding Naming Policy Options.
IMPORTANT:We recommend reviewing and, if appropriate for your environment, changing the default naming policy before you provision users to the SaaS applications. If you change a naming policy after users have already been provisioned, you must either remove the users from the policy mapped group for the SaaS account, and then put the users back in the group, or undo the policy mapping and then redo it. Depending on the order of operations, it might take a couple of tries for the accounts to be completely changed in the SaaS application.
You must map authorizations for the appropriate roles (groups) to enable their entitlements to the applications. For more information, see Mapping Authorizations
in the CloudAccess Installation and Configuration Guide. Users must log in with a corporate identity to access their provisioned account.
IMPORTANT:The connectors cannot provision accounts for users in a Self-Service User Store (SSUS) identity source, a SAML 2.0 Inbound (SAML2 In) internal identity store, or social identity sources such as Facebook. You should not create policy mappings between provisioning applications and SSUS, SAML2 In, or social (Facebook, etc.) identity sources.
CloudAccess creates a new account or merges an existing account in the SaaS applications for users who are members of groups in the identity sources that you map for entitlements to the applications. This is called provisioning.
Account provisioning occurs in one of the following ways:
Automatic: CloudAccess provisions an account for users who are members of groups that are entitled to use the application.
If approval is not required when you configure policy mapping, an account is provisioned when you map authorizations for the SaaS applications to the identity source roles.
If approval is required, the account is not provisioned until the request is approved.
User-controlled (Salesforce only): You can configure the connector for Salesforce to allow users control of when their accounts are provisioned. A configuration option is available on the connector to Prompt users for an existing account before provisioning.
When you select this option, users have two choices during their initial attempt to access the Salesforce application using single sign-on through CloudAccess:
I do not have an existing account. Create one for me.
I already have an existing account. These are my credentials:
When it provisions a new account, CloudAccess determines if a matching user account already exists in the SaaS application. This search occurs whether the provisioning method is automatic or user controlled.
If a match is found, CloudAccess merges the user with the existing SaaS application account. For more information, see Section 2.4.5, Matching Criteria for Merging Existing Accounts.
If no match is found, CloudAccess creates a new account. For more information, see Section 2.4.4, CloudAccess Default Naming Convention for Newly Provisioned Accounts.
Whether CloudAccess merges the user account or creates a new account, the user’s SaaS application password is set to a random value that CloudAccess generates. The user’s authentication to the SaaS application now uses federated single sign-on with SAML 2.0. CloudAccess sends information about an authenticated user to the destination application using an assertion or token. The user does not log in directly to the application. For information about single sign-on for users, see Section 2.3, Providing Access to Applications for Users.
The examples in this section describe the experience for automatic account creation and user-controlled provisioning (that is, when the Prompt users for an existing account before provisioning option is enabled on the connector for Salesforce).
Sample experience with the automatic account provisioning:
The administrator maps one or more SaaS authorizations to the identity source role (group).
(Conditional) If approval is required, the person with the Approval role approves or denies the account creation.
CloudAccess searches for an existing, matching account.
CloudAccess merges an existing matching account. If CloudAccess finds a matching account, CloudAccess merges the existing account with the new account it creates for the user. For example, the user’s mail attribute in the identity source matches a user name in the Salesforce domain.
Or
CloudAccess provisions a new account. If CloudAccess does not find a matching account, CloudAccess creates a new account for the user in the SaaS application, following the naming conventions in Table 2-1.
Users log in to CloudAccess with their corporate credentials, and CloudAccess authenticates them against the identity sources.
CloudAccess presents users with appmarks for the SaaS applications they are entitled to access.
Users click the appmark for the entitled SaaS application they want to use.
CloudAccess uses single sign-on to authenticate the users to the SaaS application.
Sample experience with user-controlled account provisioning (Salesforce only):
The administrator selects the Prompt users for an existing account before provisioning option when configuring the connector for Salesforce.
The administrator maps one or more Salesforce authorizations to the identity source role (group) and grants approval, if required.
(Conditional) The person with the Approval role approves or denies the account creation.
Users log in to CloudAccess with their corporate credentials, and CloudAccess authenticates them against the identity sources.
CloudAccess presents users with appmarks for the Salesforce applications they are entitled to access.
Users click the appmark for the entitled application they want to use.
CloudAccess presents two options to users:
I do not have an existing account. Create one for me.
I already have an existing account. These are my credentials:
Regardless of the option the user selects, CloudAccess searches for an existing, matching account.
CloudAccess merges an existing matching account. If CloudAccess finds a matching account, CloudAccess merges the existing account with the new account it creates for the user. For example, the user’s mail attribute in the identity source matches a user name in the Salesforce domain.
Or
CloudAccess provisions a new account. If CloudAccess does not find a matching account, CloudAccess creates a new account for the user in Salesforce, following the naming conventions in Table 2-1.
CloudAccess uses single sign-on to authenticate the users to Salesforce.
CloudAccess contains a default naming convention for creating the user accounts in the SaaS applications.
Table 2-1 CloudAccess Naming Convention
|
Identity Source |
Connector for Google Apps |
Connector for Microsoft Office 365 |
Connector for Salesforce |
Connector for ServiceNow |
|---|---|---|---|---|
|
Active Directory |
sAMAccountName |
sAMAccountName@Federated Domain Name |
sAMAccountName@Salesforce Domain Name |
CN |
|
eDirectory |
CN |
CN@Federated Domain Name |
CN@Salesforce Domain Name |
CN |
|
JDBC |
CN |
CN@Federated Domain Name |
CN@Salesforce Domain Name |
CN |
As shown in Table 2-1, the user name attribute for Office 365 and Salesforce are in the form of an email address. For Office 365, CloudAccess creates a unique user name based on the sAMAccountName or CN of the user object in the identity source prepended to the federated domain name configured for the organization in the Office 365 account. For Salesforce, CloudAccess creates a unique user name based on the sAMAccountName or CN of the user object in the identity source prepended to the domain name configured in the company profile at the Salesforce account.
The following sections define the matching criteria of the connectors that provision users:
Table 2-2 contains the matching criteria for the connector for Google Apps. CloudAccess compares the Google Apps email attribute value to the listed identity source attribute value. If there is a match, CloudAccess merges the accounts. If there is no match, CloudAccess creates a new account in Google Apps. The display name is the user-friendly name for the attribute parameter that it represents.
Table 2-2 Google Apps Matching Criteria
|
Source |
Display Name |
Attribute Name |
|---|---|---|
|
Google Apps |
|
Username |
|
Active Directory |
User logon name |
sAMAccountName |
|
eDirectory |
Username |
CN |
|
JDBC |
Username |
CN |
Table 2-3 contains the matching criteria for the connector for Office 365. CloudAccess compares the Office 365 userPrincipalName attribute value with the value in the identity source attribute plus the @ sign plus the Office 365 federated domain name. If the values match, CloudAccess merges the accounts. If there is no match, CloudAccess creates a new account in Office 365. The display name is the user-friendly name for the attribute parameter that it represents.
Table 2-3 Office 365 Matching Criteria
|
Source |
Display Name |
Attribute Name |
|---|---|---|
|
Office 365 |
User name |
userPrincipalName (upn) |
|
Active Directory |
User logon name@Federated Domain Name |
sAMAccountName@Federated Domain Name |
|
eDirectory |
Username@Federated Domain Name |
CN@Federated Domain Name |
|
JDBC |
Username@Federated Domain Name |
CN@Federated Domain Name |
Table 2-4 contains the matching criteria for the connector for Salesforce. CloudAccess matches on three different attributes in a priority order. If CloudAccess does not find a match for the value in the first attribute, it performs a search on the value of the second attribute, and if it does not find a match, it performs the search for the value in the third attribute. The display name is the user-friendly name for the attribute parameter that it represents.
Table 2-4 Salesforce Matching Criteria
|
Source |
Display Name |
Attribute Name |
|---|---|---|
|
First Priority |
|
|
|
Salesforce |
Federation identifier |
N/A |
|
Active Directory |
N/A |
objectGUID employeeID |
|
eDirectory |
N/A |
GUID workforceID |
|
JDBC |
N/A |
N/A |
|
Second Priority |
|
|
|
Salesforce |
Username |
Username |
|
Active Directory |
User logon name@Salesforce Domain Name |
sAMAccountName@Salesforce Domain Name |
|
eDirectory |
Username@Salesforce Domain Name |
CN@Salesforce Domain Name |
|
JDBC |
Username@Salesforce Domain Name |
CN@Salesforce Domain Name |
|
Third Priority |
|
|
|
Salesforce |
Username |
Username |
|
Active Directory |
|
|
|
eDirectory |
E-mail Address |
Internet EMail Address |
|
JDBC |
N/A |
N/A |
Table 2-5 contains the matching criteria for the connector for ServiceNow. CloudAccess matches on two different attributes in a priority order. CloudAccess tries to match existing accounts first by CN, then by email address. If CloudAccess does not find a match for the value in the first attribute, it performs a search on the value of the second attribute. The display name is the user-friendly name for the attribute parameter that it represents.
Table 2-5 ServiceNow Matching Criteria
|
Source |
Display Name |
Attribute Name |
|---|---|---|
|
First Priority |
|
|
|
ServiceNow |
Username |
CN |
|
Active Directory |
User logon name |
sAMAccountName |
|
eDirectory |
Username |
CN |
|
JDBC |
Username |
CN |
|
Second Priority |
|
|
|
ServiceNow |
|
|
|
Active Directory |
|
|
|
eDirectory |
Email-address |
Internet Email address |
|
JDBC |
|
|
Before you map users to the appropriate applications to set their entitlements, you can specify the naming policy that the SaaS connectors should use for each user account when provisioning users.
Naming policies are used for both newly provisioned accounts and matching accounts. New accounts are named according to the naming policy you specify. For an existing account, the connector tries to match it, and if it finds a matching account, it renames the account if necessary to match the policy.
NOTE:CloudAccess does not currently have any selection criteria for the naming policy for ServiceNow. Whatever the CN attribute is when the user is imported, that is the user name that is created in ServiceNow.
The user name attribute for Office 365 is in the form of an email address. If you do not specify a naming policy, by default the connector creates a unique user name based on the sAMAccountName or CN of the user object in the identity source prepended to the federated domain name configured for the organization in the Office 365 account.
The following table shows how the connector for Office 365 handles an example user named John Q Public, with the samAccountName jpublic in Active Directory, depending on the naming rule you select.
Table 2-6 Rule Options
|
Option |
AD Attributes |
Office 365 Account (in the ag4c.com domain) |
|---|---|---|
|
UserName (default option) |
samAccountName |
jpublic@ag4c.com |
|
Firstname.Lastname |
firstname + lastname |
john.public@ag4c.com |
|
FirstInitial + Lastname |
substring(1)firstname + lastname |
jpublic@ag4c.com |
|
Firstname + MiddleInitial + Lastname |
|
johnqpublic@ag4c.com |
The SaaS connectors can usually handle certain special characters, such as apostrophes (‘), double quotes (“), and back-ticks (‘) in user names. The connectors handle spaces and apostrophes as follows:
If any of the values, such as the middle initial, are blank in the identity source, the connectors ignore them and leave them out of the name sent to the SaaS applications.
Office 365: If you have a user name containing an apostrophe, the connector will change the user account and keep the apostrophe in place. For example, if you set the naming rule to firstname.lastname and you have a user name of Mike O’Shea, the connector will change the user account to Mike.O’Shea@ag4c.com. The email address will also include the apostrophe.
Google Apps: If you have a user name containing an apostrophe, the connector will strip out that character. For example, if you set the naming rule to firstname.lastname and you have a user name of Mike O’Shea, the connector will send the account name oshea to Google.
Salesforce: The connector for Salesforce is currently unable to handle apostrophes in the user name. We recommend that you remove any apostrophes in username, firstname, and lastname to avoid provisioning failures.
ServiceNow: The connector for ServiceNow handles spaces, apostrophes, and other special characters as expected. For example, the connector creates john smith as john smith, and creates karen.o’malley as karen.o’malley.
If you change a user name in the identity source, such as jpublic to john.public, the Office 365 user will not lose any existing email, and the user’s new email address will be john.public@ag4c.com. However, it might take a few minutes for the mailbox to be ready to accept emails after a name change.
CloudAccess handles collisions during provisioning using the Veto method. If there is a duplicate user name, the first user is provisioned, but the second user is not. For example, if you have a user named John Q. Public and a user names Jack D. Public, and your naming policy is set to FirstInitial + Lastname, the workflow is as follows for Google Apps (assuming John is provisioned first):
CloudAccess provisions jpublic@ag4c.com as expected.
The connector searches for jpublic and finds a match. However, since he has already been provisioned, the connector recognizes that this is not the same account and shows an error in the googleapps connector logs similar to the following:
> DirXML Log Event ------------------- > Driver: \IDVAULT\system\driverset1\connectors_GOOGLEAPPS_VXE3T > Channel: Subscriber > Object: \IDVAULT\data\users\jackpublic > Status: Error > Message: Code(-9063) Object matching policy found an object that > is already associated: data\users\johnpublic
where johnpublic is the existing object that was provisioned first.
You can download the logs for the SaaS connectors using the troubleshooting tools in CloudAccess. For more information, see Section 14.1, Using Troubleshooting Tools for Application Access Issues.
NOTE:The potential for collisions increases with some of the naming policy options, such as firstname.lastname. Consider carefully whether you need to change the default naming policy of user name. Since the CloudAccess namespace is a flat tree (all users go into the ou=users container) and all names must be unique, the potential for collisions when using the default naming option is eliminated.
The connector can handle up to 999 collisions. After 999 collisions, the connector stops provisioning new accounts and logs an error in the connector log file, with a message similar to the following: “A user with this user principal name already exists.”