Skip to main content

Configuring Google

Domain Management

Currently, Google connector supports only one domain. Add a domain name to fetch information from that domain.

WARNING

To manage more than one domain, install the connector again. Reach out to support to help with multi-domain management using single connector.

Attribute Sync Direction

While adding attribute in json file, you can choose which direction your data flows for every attribute in IDHub.

Use function syncDirection for every attribute to choose their data flow directions.

Possible values are as follows:

'bi-directional': 'Bidirectional Synchronization',
'idhub-to-app': 'Sync IDHub to Application only',
'app-to-idhub': 'Sync Application to IDHub only',
'no-sync': 'No Synchronization'

Based on attribute functions we recommend directions. See below:

  • RBAC (Role based Access Control) : app-to-idhub or bi-directional
  • Reporting and not sensitive : bi-directional
  • Modify functions in target system and RBAC : idhub-to-app
  • Only for display : no-sync
  • Sensitive Attribute not used for audit/ reporting : Do not add attribute

Field Mapping

Another function in the json is to match a specific IDHub field with the target system attribute.

Use function idhubFieldName and add from IDHub field list to match the fields.

info

List of IDHub fields can be viewed in your IDHub instance in Admin Settings page in Admin Module. Target System fields can be matched with custom added IDHub field as well.

Example
{
"name": "fullName",
"type": "string",
"idhubFieldName": "displayName",
"required": true,
"syncDirection": "bi-directional"
}

Here target system attribute fullName is mapped with IDHub attribute displayName.

Multi-value Field

For making an attribute multi-valued in IDHub, use function multivalue and mark it as true. Some common examples are email addresses, membership, licenses attributes which provides multiple values.

Unique Field

Every target system provides at-least one unique attribute to distinguish their accounts. To mark that attribute as unique account name (In case multiple unique keys are present and you do not wish for IDHub to fetch all unique keys and mark only one as account name) use function uniqueness and value can be server or global

note

Reconciliation will fail if more than one attribute is added as unique.

For Google, below are some of the attributes among others that can be unique account name.

  • id
  • primaryEmail - Recommended
  • secondaryEmail
  • recoveryEmail

Reconciliation Key

Possible unique reconciliation key to match account in Google with User in IDHub are as follows:

  • primaryEmail (Google) with email (IDHub) - Recommended
  • id (Google) with login (IDHub)
  • secondaryEmail (Google) with email (IDHub)

Use function

  • isRecon and mark as true AND
  • mutability and mark as immutable

Both functions need to be added to the attribute to mark it as a reconciliation key.

Example : Below is a primaryEmail attribute which is marked as Reconciliation key.
{
"name": "primaryEmail",
"type": "string",
"idhubFieldName": "email",
"required": true,
"isRecon": true,
"mutability": "immutable",
"uniqueness": "server",
"syncDirection": "bi-directional"
}

More than one attribute can be used as reconciliation key. It is used to match IDHub users with accounts and combination of reconciliation keys will be used to match the account.

Manager Operations

The Google connector supports the manager attribute for the following:

  • Reconciliation: On account reconciliation, the manager attribute for a user populates for a non-null (blank) value on the Google domain. Add the manager attribute in the account schema with the string type and sync direction as bi-sync or app-to-idhub for getting manager information in IDHub
  • Provisioning: The manager attribute is supported for the Add, Remove, and Edit operations where the value of the manager can be set base on an existing user’s primaryEmail. If the syncDirection for manager is idhub-to-app OR bi-directional, then on user attribute modification, our connector sends updated manager information to Entra which adds the new manager in Entra automatically. If manager information provided is not present in Entra, then change requested will not be reflected in Entra.