2.3 Identity Source Requirements

Use the information in the following sections to verify that your identity source meets all requirements before you deploy the appliance. For CloudAccess to provision user accounts to the SaaS applications, each user account in the identity source must contain the attributes listed.

2.3.1 Active Directory Requirements

Verify that your Active Directory environment meets the following requirements:

  • Windows Server 2012 R2 or Windows Server 2008 R2.

  • A unique identity for each user account, whether you have one or more domains or identity sources. The appliance uses the sAMAccountName as the unique identifier for the users.

To provision user accounts from Active Directory to the SaaS applications, all of the following attributes must be populated on the Active Directory users:

  • First name

  • Last name

  • Full name (Display name is the field that populates this attribute.)

  • sAMAccountName or Logon Name (Pre-Windows 2000)

  • User Principal Name (UPN)

  • Email address

Obtain the following required items:

  • The password and the fully distinguished LDAP-formatted name of a user in Active Directory who has read access to the user objects. The appliance will use this user account to make LDAP binds to Active Directory.

  • The name and password of a user in Active Directory who becomes the administrator of the appliance. The user must reside in the user search context specified during the appliance initialization procedure.

  • The IP address of one or more Active Directory servers that contain the users.

  • The context of the users in Active Directory.

2.3.2 eDirectory Requirements

Verify that your eDirectory environment meets the following requirements:

  • eDirectory 8.8 SP7 or eDirectory 8.8 SP6.

  • A unique identity for each user account, whether you have one or more eDirectory trees or identity sources.

To provision user accounts from eDirectory to the SaaS applications, all of the following attributes must be populated on the eDirectory users:

  • CN (Username is the field that populates this attribute.)

  • Given Name (First name is the field that populates this attribute.)

  • Internet EMail Address

  • Surname (Last name is the field that populates this attribute.)

Obtain the following required items:

  • The password and fully distinguished LDAP-formatted name of a user in eDirectory who has the following rights. The appliance will use this user account to make LDAP binds to eDirectory:

    • Property Rights

      • CN: compare, read, inherit

      • Description: compare, read, inherit

      • Given Name: compare, read, inherit

      • GUID: compare, read, inherit

      • Internet EMail Address: compare, read, inherit

      • Login Disabled: compare, read, inherit

      • Member: compare, read, inherit

      • Group Membership: compare, read, inherit

      • Surname: compare, read, inherit

    • Entry Rights: browse, inherit

  • The name and password of a user in eDirectory who becomes the administrator of the appliance. The user must reside in the subtree of the search context for the identity source specified during the initialization of the appliance.

  • The IP address of one or more eDirectory servers that contain a replica of the partition holding the user objects and that run NLDAP.

  • The context of the users in eDirectory.

2.3.3 JDBC Requirements

In order to use the JDBC database as an identity source, you must know and understand JDBC databases. The information provided in this section is for database administrators.

Meeting the Requirements

Verify that you meet following requirements or obtain the following information before using a JDBC database as an identity source:

  • The supported type of JDBC database. (Microsoft SQL Server 2008 or 2014, Oracle Database 10.2 or 11.1)

  • The IP address of the JDBC database.

  • The port for communication. The default port is 1433 for Microsoft SQL or 1521 for Oracle Database.

  • The database name or sid. (idm for Microsoft SQL defines as the sid in Oracle Database)

  • The script files must be installed before you can configure a JDBC database as an identity source. For more information, see Obtaining the Script Files.

  • The password for the user name in the sample scripts you install. For more information, see Obtaining the Script Files.

Obtaining the Script Files

In order to use JDBC as an identity source, you must install script files on your JDBC database so that CloudAccess knows what tables to read to access the users and groups information. You download the script files when you configure the JDBC identity source.

You can download the files during the initialization process, if you select JDBC as your identity source, or you can download the scripts when you configure JDBC as an identity source after the appliance is initialized. You download a single zipped file that contains multiple scripts.

The different scripts are:

  • indirect_install: Installs the schema, which includes the indirect tablespace and proc_authuser () stored procedure, as well as the automatic triggers for the indirect.user and indirect.grp tables.

  • copy_from: Copies user account information from the database default user store into the indirect.usr table for processing by the connector for JDBC.

  • unistall: Removes the schema and deletes or drops the connector user accounts in the underlying database.

Populating the Required Columns

To provision users from the JDBC databases to the SaaS applications, you must have the following columns populated for each user account in the JDBC database:

  • indirect.usr.idu

  • indirect.usr.username

  • indirect.usr.fname (Mandatory only for Google Apps accounts)

  • indirect.usr.lname

  • indirect.usr.email (Mandatory only for Salesforce accounts)

Dataflow Information

The connector for JDBC uses indirect tables to gather the needed information. This ensures that the appliance does not work directly with the information in the database. The following graphic depicts how the connector for JDBC obtains the information from the JDBC database. This process is the same no matter what type of database the appliance connects to.

Figure 2-1 Dataflow of User Information

The database administrator creates the user accounts or logs in to the user$ table. (The dataflow figures are based on the default Oracle security table user$.) The database administrator defines triggers or procedures that copy information into the indirect.usr table.

The indirect_install .sql script creates the automatic insert, update, or delete triggers on the indirect.usr table. When rows in the indirect.usr table are altered, the automatic triggers add a row to the indirect.indirect_process table.

The appliance polls the indirect.indirect_process table. When the appliance detects rows in the indirect.indirect_process table of type user, the appliance adds, modifies, or deletes the user account in the applications connected to the appliance.

The appliance then deletes the row from the indirect.indirect_process table after the appliance processes the information.

Figure 2-2 Dataflow of Group Information

The database administrator performs a direct or triggered insert of data into the indirect.grp table.

The indirect_install .sql script creates the automatic insert, update, or delete triggers on the indirect.grp table. When rows in indirect.grp are altered, the automatic triggers add a row to the indirect.indirect_process table.

When the appliance detects rows in the indirector.indirect_process table of type group, the appliance adds, modifies, or deletes the groups in the applications connected to the appliance. The appliance then deletes the row from the indirect.indirect_process table after the appliance processes the information.

Figure 2-3 Relationship between Users and Groups

The indirect schema does not have a direct concept of group membership, but maintains a relationship between the user idu column and the group idg column in the tables indirect.grp_member and indirect.usr_mbr_of table.

For group membership, the desired group idg and user idu must exist in both tables. The indirect install .sql script creates the automatic insert, update, or delete triggers on the indirect.grp_member and indirect.usr_mbr_of tables. When rows in these tables are altered, the automatic triggers add a rows to the indirect.indirect_process table.

When the appliance detects rows in the indirector.indirect_process table for group membership, the appliance adds, modifies, or deletes the group memberships in the applications connected to the appliance. The appliance then deletes the row from the indirect.indirect_process table after the connector processes the information.For example, if the administrator wants to add a user with idu 6 to a group with idg 10, they would have to manually (or through triggers) add entries into both the grp_member and usr_mbr_of tables.

"INSERT INTO indirect.grp_member(idg,idu) VALUES(10,6); INSERT INTO indirect.usr_mbr_of(idu,idg) VALUES(6,10);”

Figure 2-4 Authentication Process

To verify authentication credentials, the appliance calls a stored procedure indirect.proc_authuser with the parameters of @username,@password. The procedure compares the username parameter with the default user table (user$) and the indirect.usr.username fields. If they matched, the process checks the indirect.usr.disabled flag (disabled > 0 = disabled). If login is enabled (disabled = 0), the process compares the password parameter to the existing password hash in the user$ table. If the password hash matches, then the process authenticates the user successfully. If any of these conditions are not met, then the process returns an SQLException to the appliance, and authentication fails.

You can alter the stored procedure based on the desired schema that the database administrator wishes to use for authentication. The administrator needs to keep in mind that the stored procedure indirect.proc_authuser(@username,@password) is hard-coded into the appliance, and expects either a success (1) or SQLException returned.

2.3.4 Self-Service User Store Requirements

The Self-Service User Store is an internal identity source you can use with the appliance. However, you can only use this identity source after you configure the appliance. The Self-Service User Store cannot be used during the initialization process of the appliance.

There are no specific requirement to use this service. For more information, see Section 3.7.1, Configuring Self-Service Registration and Password Management.