Before you configure SAML/Account Management connectors and begin provisioning users to SaaS applications, read the following sections to ensure that you understand SAM provisioning behavior:
SaaS Account Management supports provisioning of users from the LDAP user stores that you have implemented in your Access Manager environment. To provision users using SAM connectors, certain minimum attributes must be populated in your user store.
Table 3-1 Essential User Store Attributes
|
User Store |
Attributes |
|---|---|
|
eDirectory |
|
|
Active Directory |
|
Once the mail attribute is populated in the user store, if the user is in the search context configured for the Access Manager user store, the Psearch service in SAM starts processing the user. If the user is also a member of one or more mapped groups, SAM provisions the user to the SaaS application.
For all of the SAML/Account Management connectors, the user store email attribute is the preferred naming value when searching for and creating new accounts in the target SaaS systems. In some cases, the SAM provisioning process does not find the existing user SaaS account based on email address when doing a GET call to see if the account already exists in the target system. If the GET call returns a “Not Found” error, the SAM process then issues a POST request and tries to create a new account in the target SaaS system.
In some cases, even though the GET request returned a “Not Found” error, the POST process, because of connector API logic, may match on the existing user account based on another attribute (such as immutableID in Office 365 or UserName in ServiceNow). In these cases, it is possible that the SaaS account login name may change to match the POSTed email address from the SAM provisioning service. If this happens, you must inform your end users that their loginName (UserName) in the target SaaS system has changed to match their email address in your LDAP user store.
The following tables explain how attribute account matching works for each of the SAML2/Account Management applications.
Table 3-2 Box
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Box. After SAM claims and synchronizes the account, the Box user’s username remains the same. |
|
Table 3-3 Dropbox
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Dropbox. |
|
Table 3-4 Docusign
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Docusign. |
|
Table 3-5 Google Apps
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (name part only, case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Google. |
|
Table 3-6 LogMeIn Apps
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in LogMeIn. |
|
Table 3-7 Office 365
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Test 1: Email (name part only, case-sensitive) |
UserPrincipalName (name part only) |
|
Test 2: Email (name part only, case-insensitive) |
UserPrincipalName (name part only) |
|
Test 3: GUID |
ImmutableId |
|
If SAM detects a matching user with any of the three tests, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Office 365. After SAM claims and synchronizes the account, the Office 365 user’s UniversalPrincipalName is <ldapEmailNamePart>@<o365DomainName>. |
|
Table 3-8 Salesforce
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Test 1: Email (name part only, case-insensitive) |
|
|
Test 2: Email (name part only, case-insensitive) |
Username |
|
If SAM detects a matching user with either test, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Salesforce. After SAM claims the account, the Salesforce user’s Email and Username are the value of the user’s LDAP email. |
|
Table 3-9 ServiceNow
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Test 1: Email (name part only, case-insensitive) |
|
|
Test 2: Email (name part only, case-insensitive) |
User ID |
|
If SAM detects a matching user with either test, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in ServiceNow. After SAM claims and synchronizes the account, the ServiceNow user’s Email and User ID are the value of the user’s LDAP email. |
|
Table 3-10 Tableau
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Tableau. |
|
Table 3-11 Zendesk
|
LDAP user attribute used for matching |
SaaS user attribute tested for match |
|---|---|
|
Email (case-insensitive) |
|
|
If SAM detects a matching user, SAM “claims” the user account and synchronizes a subset of attributes from the LDAP user store to the user account in Zendesk. |
|
For each SAML2/Account Management application, SAM attempts to match *qualified users from the Access Manager LDAP user stores to existing user accounts, if any, at the respective SaaS provider. To determine whether an Access Manager user is the same user as or a different user than an existing SaaS user, SAM compares one or more attributes between the LDAP and SaaS user. If SAM finds a match, SAM **claims and manages the account at the SaaS provider. If SAM does not find a match, SAM provisions a new user account at the SaaS provider.
WARNING:To prevent unwanted account claiming, you must ensure that the values for the user’s email address are unique across all user stores for all active, disabled, and deleted users, and must not match existing SaaS user accounts except when those users are the same user.
*Qualified users are those who:
Reside within the search contexts of the eDirectory or Active Directory user stores configured in Access Manager.
Have at least the following attributes populated: firstname, lastname, and email address.
Are members of one or more groups that are mapped in the SAML2/Account Management applications.
** Claiming a user account means that the Access Manager user with the matching account is able to log in to that account and sees the expected content of the existing SaaS user. For example, if the SaaS application is an email service, the matching Access Manager user sees whatever email exists for that user in the SaaS when the account is claimed. SAM then synchronizes certain user attributes from the Access Manager user store to the SaaS user account.
When SAM provisions users to Google, SAM creates the login name at Google from the name part of the LDAP user’s mail attribute prepended to the Google domain name. For example, if the LDAP user’s mail attribute is jdoe@novell.com and the Google domain is mygoogledomain.info, the resulting user account at Google would be jdoe@mygoogledomain.info. For SAML single sign-on between Access Manager and Google to be successful for this user, the value of NameID in the assertion must be jdoe. You must perform this “mapping” of a local attribute into the SAML assertion using the Access Manager administration console.
In the Access Manager administration console, go to Applications > Google > Attributes. From the Mapped to System Attribute list, select an attribute that contains the same value as the username portion of the user’s email address. Often, the LDAP attributes cn, uid, or LDAP User Name [Credential Profile] are populated with this value. If so, you can choose any of these attributes from the list. In cases where the user objects do not have an attribute with the same value as the username part of the email address, you can create a virtual attribute that extracts the username from the mail attribute. For example, you could create a virtual attribute similar to the following:
Name: extractName
Input parameters:
Name: P1
Parameter value: mail
Modification function:
Function: Regex Replace
Regex: /@(.*)$/
Replace with: <empty>
After you create the virtual attribute, that attribute will be available for selection in the Mapped to System Attribute list of the Google application. For more information about virtual attributes, see the NetIQ Access Manager 4.5 Administration Guide.
Before you use SaaS Account Management to provision users, it is important to understand how SAM interacts with SaaS providers and how user logins change for existing SAML accounts. For the purposes of this section, ServiceNow is the SaaS provider.
After configuring Account Management, you add a user into the mapped group in the LDAP user store, and Psearchservice recognizes that the account is now “in scope” for provisioning.
Psearchservice uses the LDAP email address to try to match the account in ServiceNow, first checking the user name in ServiceNow, then the email in ServiceNow.
If Psearchservice finds a match on either attribute in ServiceNow, Psearchservice claims the account, sends a PATCH, and sets the ServiceNow SaaS account’s user name and email to the LDAP user store email value.
If Psearchservice does not find a match, Psearchservice sends a POST, and SAM creates a new account in ServiceNow.
You have manually created accounts in ServiceNow, and users are logging in with their user names and passwords, referred to as local login. You then decide to use Access Manager and SAM for account management. For the purposes of this example, the user’s email and user name are the same in the LDAP user store and in the SaaS system. Psearchservice performs its standard workflow and claims the account. In doing so, SAM updates the password in ServiceNow, and local logins no longer work.
IMPORTANT:Once you enable SAM for Account Management, all users log in using SAML, and local logins using user name and password are no longer valid.
The user is using a local login in ServiceNow. His ServiceNow user name is bob@servicenow.com and his ServiceNow email is robert@servicenow.com (which is acceptable in ServiceNow). His LDAP user store email is robert@servicenow.com.You then decide to use Access Manager and SAM for account management, and put the user "in scope" for account management. Psearchservice performs its standard workflow and claims the account.Once Psearchservice has claimed the account, the PATCH from SAM sets both the ServiceNow user name and ServiceNow email to robert@servicenow.com. This means that the ServiceNow user name has changed to the same value as the email address.As in Example 1, local logins no longer work, because both the password and ServiceNow user name have changed. Federated SAML2 authentication does work.
Most companies define their business policies through authorization assignments. When you configure SAML2/Account Management applications, SaaS Account Management allows you to map groups in your Access Manager user stores to specific authorizations in the SaaS applications. You can map authorizations for all SAML2/Account Management applications that provision users, such as Office 365, Google Apps, Salesforce, and ServiceNow.
For provisioning to occur, you must select at least one LDAP group on the LDAP Groups and Authorizations page. For authorizations to be assigned, you must map them to the LDAP groups you have selected. SAM then processes and provisions to the SaaS applications the LDAP users who are members of the mapped groups and who have the required firstname, lastname, and email attributes. If you do not specifically assign SaaS authorizations, the LDAP users get only basic accounts.
Each user store can contain different groups that appear on the LDAP Groups and Authorizations page in Access Manager. Active Directory user stores can contain groups, local groups, and global groups. eDirectory user stores can contain groups.
NOTE:SAM supports mapping authorizations to LDAP user groups, but not to Access Manager roles. Certain SaaS applications might include authorizations for roles, but these are not the same thing as roles in Access Manager.
Each SAML2/Account Management application contains different authorizations that appear on the LDAP Groups and Authorizations page in Access Manager. For example, Office 365 has account, group, and license authorizations.
If a user is a member of multiple selected groups, the authorizations are cumulative. If you map any authorization to a user store group and later remove that authorization, members of that user store group lose that authorization, unless they are also members of another user store group that still has that authorization mapping.
IMPORTANT:Use caution when mapping authorizations. SaaS authorizations change frequently, so SaaS Account Management simply presents the available authorizations and does not attempt to restrict any mappings that might conflict at the SaaS application. For example, Google allows a user to exist in only one Organizational Unit or User Placement, but you can map multiple user placements to the same LDAP group or to several LDAP groups where the same user might be a member.
We assume that you are familiar with and understand the authorizations available for each SaaS application to which you are provisioning users. As a best practice, we recommend that you test any mapped authorizations in a non-production environment to ensure that they work as expected before you implement them in your production environment.
For additional information about authorization mapping behavior that is specific to Google Apps, see Understanding Google Apps Authorization Mappings.
Mapped placement of newly provisioned users to a sub-organization overrides the default placement in the top-level organization.
IMPORTANT:Pay careful attention when mapping User Placement authorization values to user store groups to ensure that you place users in the intended Google Apps organizations. Google Apps allows each user to be placed in only one organization at a time. If you grant a User Placement authorization to a user, and then grant another User Placement authorization to the same user, the first value is overwritten when the user is moved in the Google Apps organizational unit structure.
In addition, if you revoke a User Placement authorization for a user, even if that user has multiple User Placement authorizations, that user is moved to the default organization specified in the Google Apps connector configuration. (Because Google Apps allows a user to be placed into only one organization at a time, when a User Placement authorization value is overwritten, there is only one value that is removed, which moves the user back to the default placement.) If you want to move that user from the default location back into a new Google Apps sub-organization, you must add the user back to the appropriate user store group and perform authorization mappings again.
If you revoke a User Account authorization for a user after the user has been provisioned into Google Apps and one or more User Placement authorizations have been granted to the user, that user is placed in suspended mode in Google Apps. No placement activity takes place as long as the user account is suspended; the user simply remains in the Google Apps organization that the user was in before the suspension. When you re-grant the User Account authorization, the account is moved to the “active user” state. If you performed a User Placement authorization change while the user account was suspended, the user is moved to the appropriate organization after the account is reactivated.