Skip to Content

User and group provisioning in Jitterbit App Builder

App Builder supports automated user and group provisioning. Provisioning reduces administrative burden by minimizing manual creation of users and groups within App Builder.

Provisioning strategies

Provisioning strategies fall into one of two categories:

  1. Just-In-Time (JIT) - User accounts are created on-demand during the sign-in process.
  2. Service Provider (SP) APIs - Identity Providers (IdPs) manage users and groups via SP-supplied APIs.

Each approach has advantages and disadvantages.

Drawbacks to JIT provisioning include:

  • Users cannot be deprovisioned.
  • The SP does not have a complete list of users and groups.
  • Users and groups may get out-of-sync if users and groups do not have an immutable identifier (such as a GUID or SID).

Drawbacks to SP APIs include:

  • Most SP APIs are proprietary (Salesforce, Azure, Google, etc.). Emerging standards, such as System for Cross-Domain Identity Management (SCIM), are not commonly deployed.
  • An SP API is more complicated to set up, often requiring custom coding.
  • All users need to be registered with the SP. Existing user accounts need to be bulk registered during the initial setup.

App Builder's provisioning strategy

App Builder implements JIT provisioning at the security provider level. When enabled, App Builder creates user accounts after successfully validating security tokens (such as a SAML assertion or OAuth 2.0 authorization code).

When configuring user provisioning, administrators may indicate whether the security token includes group membership. In which case, App Builder will extract the groups from the security token, registering the them within App Builder and associating the user with those groups. Note that not all authentication schemes support this option. Review the security provider documentation for further information.

As noted above, the JIT strategy does not support user deprovisioning. App Builder mitigates this limitation by disallowing local login. Specifically, if the user account has not been assigned a password, the user will not be able to log into App Builder directly. Regardless, security administrators will need to log into App Builder and delete any orphaned user accounts.

Enabling provisioning

User provisioning presupposes that authentication is delegated to an Identity Provider (IdP). As such, user provisioning requires an authentication security provider such as a Single Sign-On (SSO) security provider. Examples include SAML SSO (such as Okta), WS-Federation (Azure Active Directory or Active Directory Federation Services) or other external authentication providers (e.g. Salesforce).

User provisioning is disabled by default and must be enabled by a security administrator. To enable user provisioning:

  1. Navigate to the IDE.
  2. Click on Security Providers.
  3. Double-click the applicable Security Provider from the User Authentication panel.
  4. Click Edit on the Provider panel.
  5. Check the User Provisioning option.
  6. Click the Save button.

Mapping identities to existing users

By default, the user provisioning process will create new user accounts, but it will not map an identity to an existing account. Provisioning will fail if a user exists with the given name.

If the IdP is a trusted, single source of authority, consider enabling the Match Existing User option. This option allows the provisioning process to map an identity to an existing user with the same name. The mapping only takes place if the user account does not already have an identity associated with the security provider.

The Match Existing User option is available after enabling User Provisioning.

Configuring authorization

Provisioning users is only one piece of the puzzle. By default, new user accounts will not have access to any applications. To fully automate the provisioning process, administrators will want to ensure that new users are granted appropriate privileges when signing in. There are 4 approaches that can be taken:

  • By default, new users are added to the Users security group. Administrators can grant the Users group access to one or more applications. This is generally not recommended. The Users security group is intended for all authenticated users. As a result, all authenticated users will have access to the granted applications, which may not be the desired result. Also, App Builder owns the Users security group and may modify the group during an upgrade.
  • Create a new security group and enable the Grant On User Create option. When Grant On User Create is enabled, newly created users are added to the group automatically. This is preferable to option #1 because it uses a custom security group instead of the built-in Users group. However, the Grant On User Create option applies to all users, regardless of whether they are created manually via the user interface or automatically provisioned by a security provider.
  • Create a new security provider group and enable the Grant On Identity Create option. As opposed to a security group, a security provider group is specific to a security provider. As in option #2, administrators will need to create a security group and grant it access to one or more applications. However, do not enable the Grant On User Create option. Instead, create a security provider group, map it to the internal security group, and enable the Grant On Identity Create option. Using this technique, only users provisioned by the security provider will be granted privileges automatically.
  • If the security provider supplies group membership, authorization can carried down from the Identity Provider (IdP) to App Builder. App Builder will extract the group membership claims from the security token and register those groups as security provider groups. Administrators must map one or more security provider groups to internal security groups. This option takes more time to set up and may require additional configuration on the Identity Provider (IdP). However, once configured, App Builder will honor IdP-supplied group membership.

Options 3 and 4 are mutually exclusive: either App Builder or the security provider can manage security provider groups–not both. However, they can both be combined with the Grant On User Create option.