The connector for Google Apps for Business, the connector for Salesforce, and the connector for Microsoft Office 365 support both account provisioning and single sign-on. These three 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. You must map authorizations for the appropriate roles (groups) to enable their entitlements to the applications. Users must log in with a corporate identity to access their provisioned account.
The connectors cannot provision accounts for users in a Self-Service User Store (SSUS) identity source or a SAML 2.0 Inbound (SAML2 In) internal identity store.
IMPORTANT: Although CloudAccess does not prevent it, do not create policy mappings between provisioning applications and SSUS or SAML2 In 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 two 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: You can configure the SaaS connectors to allow users control of when their accounts are provisioned. A configuration option is available on the connector for Google Apps and the connector for Salesforce 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 SaaS 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 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 or WS-Federation. CloudAccess sends information about an authenticated user to the destination application by 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 is enabled).
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.
CloudAccess uses single sign-on to authenticate the users to the SaaS application.
Sample experience with user-controlled account provisioning:
The administrator selects the Prompt users for an existing account before provisioning option when configuring the connector for the SaaS application.
The administrator maps one or more SaaS 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 SaaS applications they are entitled to access.
Users click the appmark for the entitled SaaS application.
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 the SaaS application, following the naming conventions in Table 2-1.
CloudAccess uses single sign-on to authenticate the users to the SaaS application.
CloudAccess contains a defined 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 |
|---|---|---|---|
|
Active Directory |
sAMAccountName |
sAMAccountName@Federated Domain Name |
sAMAccountName@Salesforce Domain Name |
|
eDirectory |
CN |
CN@Federated Domain Name |
CN@Salesforce Domain Name |
|
JDBC |
CN |
CN@Federated Domain Name |
CN@Salesforce Domain Name |
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 |