Providers and identities in Jitterbit App Builder

Overview

Every App Builder application, data source, and web service needs a way to confirm who, or what, is making a request, and to control what that requester is allowed to do. App Builder handles both of these through security providers, which are independently configurable modules that you enable and set up to match your environment, rather than a single built-in login system. For example, one security provider might check a username and password against App Builder's own user table, another might validate an API key sent by an external system, and a third might delegate the decision entirely to a third-party identity service such as Salesforce or an SSO provider.

Some security providers also support identities: records that link a user account or group defined by an external system, such as a third-party identity provider or an external data source, to its corresponding App Builder user or security group. An identity is what lets App Builder recognize a user who signs in through an external provider as a specific, already-existing App Builder user, rather than treating every external sign-in as unknown.

This page covers:

• Providers
  The default provider types App Builder ships with, and how certain web services (REST, Webhook, and App Builder Connector) can be associated with specific providers.

• Identity management
  How providers map external user accounts and security groups to App Builder users and groups.

Providers

Not every security provider does the same job. Depending on its type, a security provider can fill one or more of the following roles:

• User authentication: Confirms the identity of a person signing in to an App Builder application.
• Data source authentication: Confirms the identity App Builder itself presents when it connects out to an external data source, such as a database or a third-party API.
• Connection-level security: Secures the underlying connection between App Builder and a data source, independently of the identity used to authenticate.
• Authorization policies: Governs what an already-authenticated user or connection is allowed to do, as distinct from confirming who they are.

Each security provider you configure defines its own set of parameters, which the site administrator sets to match your environment. App Builder ships with a default configuration that already enables a starter set of security providers, so authentication generally works out of the box; administrators can adjust, disable, or add to these as needed. You can also import and export security provider configurations.

Default provider types

App Builder ships with the following default provider types, each covering a specific authentication or authorization scheme. Select a provider's name for its configuration guide.

Web service associations

A web service, in this context, is an endpoint that external systems call into programmatically, as opposed to a page a person browses to. Since App Builder 4.67, three types of web service must each be explicitly associated with specific, individually configured providers allowed to authenticate their requests. Previously, any enabled provider of an eligible type could authenticate requests to any web service, regardless of type.

Each web service instance (each individual REST endpoint, Webhook endpoint, or Remote Connector application) is associated with specific, individually configured providers of those types, not just the type in general; the linked pages describe how to make that association. When you upgrade from an earlier App Builder version, a migration automatically associates every existing provider of an eligible type with every existing web service of the corresponding type, so existing integrations continue to authenticate without manual reconfiguration. A web service created after upgrading to App Builder 4.67 is not automatically associated with any provider, and won't authenticate any requests until you explicitly associate one.

Identity management

When a security provider delegates authentication to an external system, whether that's a third-party identity provider such as Salesforce or SAML SSO, or an external data source, App Builder needs a way to translate what that external system reports about the user into its own terms: a specific App Builder user account, and, optionally, the App Builder security groups that user's permissions should come from. This section covers the two mechanisms App Builder uses to make that translation:

• Identities, which map one external user account to one App Builder user.
• Provider groups, which map an external group, role, or scope to an App Builder security group, so a user's permissions can be derived from their external group membership, instead of assigned to each user individually.

Identities

An identity links one external user account, as reported by a specific security provider, to one App Builder user. Whenever that provider authenticates a request on behalf of an external account, App Builder needs a matching identity to know which of its own users the account corresponds to. Without one, App Builder has no way to tell which App Builder user the external account represents. A user can have only one identity per security provider, but can have separate identities for different providers, for instance if the same person is able to sign in through both Salesforce and SAML SSO.

Identities have the following properties:

• Provider: The security provider (user or data source) that owns the identity.
• Name: The unique user name assigned by the security provider. During authentication, an external identity provider typically returns a set of claims, pieces of information about the user, such as their name or a unique ID, carried in the authentication token or assertion; this property corresponds to the Name claim.
• Identifier: A unique, immutable identifier assigned by the security provider, corresponding to the NameIdentifier claim. Unlike Name, this parameter is optional, but recommended when the provider supports it, since it doesn't change even if the user's name or username later does.

Identities are required when delegating user authentication to external security providers such as Salesforce or SAML Single Sign-On (SSO). To complete sign-in, App Builder takes the claims supplied by the provider and looks for a matching identity, checking the NameIdentifier claim first and falling back to the Name claim if no match is found.

Identities also come into play for data source authentication. Most data source connections authenticate as a single, shared service account, meaning every App Builder user accesses the data source with the same credential. Some data sources, however, support user-constrained authentication, where the connection authenticates as the specific signed-in App Builder user instead. For these, the security provider uses the identity's Name if one is defined for the user, falling back to the App Builder user name if not; the identity's Identifier is not used for this purpose.

Provider groups

Beyond individual identities, an external provider may also define its own security groups, sometimes called roles or scopes, that group multiple users together, for example, a Salesforce "Sales Managers" role or a SAML IdP "Finance" group. Rather than assigning permissions to each user individually through their identity, a security administrator can map each of these external groups to a single App Builder security group, so that every user belonging to the external group automatically inherits the permissions granted to the corresponding App Builder security group.

Security provider groups have the following properties:

• Provider: The security provider (user or data source) to which the group belongs.
• Identifier: The unique name assigned to the group by the security provider.
• Group: The App Builder security group to which the security provider group is mapped.

Registration

Before a security provider group can be mapped, it must first exist in App Builder as a record. Security provider groups can be registered in one of two ways:

• Manual: Administrators log in to App Builder and add security provider groups directly. This is typically necessary for data source security providers, which have no way to report their groups to App Builder on their own.
• Automatic: App Builder registers new security provider groups on the fly, during the user authentication process, updating the user's group membership at the same time. The SAML and WS-Federation security providers support this, but only once explicitly enabled using that provider's Supplies Group Membership flag.

Mapping

Regardless of how a security provider group is registered, it can be mapped to an App Builder security group. Each security provider group can be mapped to one, and only one, App Builder security group; multiple security provider groups, however, can be mapped to the same App Builder security group.

Membership

A security provider group extends a user's App Builder security group membership rather than replacing it. When calculating a user's access rights, App Builder takes into account both the security groups the user directly belongs to, and any security groups the user belongs to by way of a mapped security provider group.