Skip to Content

Jitterbit Registration Portal App

Overview

Jitterbit provides the Registration Portal app through Jitterbit Marketplace. Built with Jitterbit App Builder, it is a self-service registration and authentication front end built on App Builder's native application authentication. It provides account registration, login, and password recovery, with two-factor authentication (2FA) by emailed verification code, configurable password and lockout policies, and an administrative dashboard for managing users, message templates, and settings.

You download the app as an App Builder release package (an .LP file) from Marketplace and install it into your own App Builder instance, where you can configure and extend it to fit your process.

This page describes how the app works, its core features and data model, and covers the prerequisites, how to download and install it, how to configure it for your environment, how access is controlled, the business rules it uses, and common troubleshooting steps.

How it works

Anonymous visitors reach three entry points: register a new account, log in, or recover a password. Registration and recovery are guided wizards that use an emailed verification code:

flowchart TD V["Anonymous visitor"] --> R["Register"] V --> L["Log in"] V --> F["Forgot password"] R --> R1["Enter email and password;
policy and duplicate checks"] R1 --> R2["Verification code emailed"] R2 --> R3["Verify code"] R3 --> A["Account created,
identity assigned"] L --> L1["Lockout checks
by email and IP"] L1 --> L2["Validate credentials"] L2 --> S["Authenticated session"] F --> F1["Enter email;
recovery code emailed"] F1 --> F2["Verify code"] F2 --> F3["Set new password"] F3 --> L

Core features

When you install and configure Registration Portal, it provides the following capabilities:

  • Self-service registration: A two-step wizard collects an email and password, enforces the configured password policy, confirms the password, and verifies a duplicate-email check without revealing whether the email already exists.

  • Two-factor authentication: Registration and password recovery issue a time-limited verification code by email. A new code invalidates any earlier one.

  • Login with lockout protection: Login validates credentials and enforces lockout thresholds by both email address and originating IP address.

  • Password recovery: A three-step wizard identifies the account, validates an emailed code, and lets the user set a new, policy-compliant password.

  • Configurable policies: Administrators manage password complexity, lockout thresholds, and environment settings from grouped policy panels.

  • Customizable messaging: Email content, on-screen messages, and the terms-of-service text are stored as editable template records, so administrators can change wording without changing the app's logic.

Data model

Registration Portal uses App Builder managed tables and enforces data boundaries by user session rather than by physical foreign-key constraints. Each table has a data usage type, set by its Install Option, that controls how its data is treated when the app is installed in a new environment.

Table Usage type Purpose
User User Identity records for self-registered accounts, including hashed credentials, verification codes, expiry values, and identity-group mapping.
LoginAttempt User Security log of authentication attempts (email, IP address, timestamp, and success), used for auditing and lockout calculations.
Session User Per-user session state, cached credentials, and access tokens, scoped to a single browser session.
Template User Localized HTML for emails, on-screen messages, and terms-of-service content.
Parameter Shared Global configuration: security provider mapping, password policy, and account/IP lockout thresholds.

Note

All tables except Session are audited.

Prerequisites

To use Registration Portal, you need the following:

  • A Jitterbit Harmony license with access to App Builder. This enables the Marketplace download; if your organization is not licensed for App Builder, the Download app action is replaced by a Get app request action (see Download and install).

  • An App Builder instance running App Builder 4.63, the version the current package is built for. Each package installs only on its exact App Builder version; if your instance is on a different version, contact Jitterbit support to request a matching package.

  • A PostgreSQL database for your App Builder instance.

  • An outbound email path from your App Builder instance. The app sends verification and recovery codes by email; without a working mail configuration, those codes do not send.

Download and install

Download the app from Marketplace

  1. Log in to the Harmony portal at https://login.jitterbit.com and open Marketplace.

  2. Locate the app named Registration Portal. You can use the search bar or, in the Filters pane under Type, select App to show only apps.

  3. Click the app card to open the Details panel. Review the app's Requirements (the App Builder version and database it needs).

  4. Click the app's Go to documentation link to open this documentation in a separate tab, and keep it open for reference.

  5. Do one of the following, depending on whether your organization is licensed for App Builder:

    • Download app: If your organization is licensed for App Builder, click Download app, on either the app card or the Details panel. Your browser saves the .LP file to its download location, and an App Builder file downloaded successfully notification confirms the download.

    • Get app: If your organization is not licensed for App Builder, the action is labeled Get app. The Details panel shows a message that an App Builder license is required, with a Submit button. Click Submit to send a request for a representative to contact you about App Builder; a Message successfully sent notification confirms it.

Install the app in App Builder

Install the downloaded .LP file into your App Builder instance:

  1. Log in to App Builder and go to the IDE.

  2. Under Deploy, click Install Release.

  3. Click + Package, then Browse and select the .LP file you downloaded.

  4. Click Save. The Release panel displays the package information, then close the Package dialog.

  5. Confirm the details are correct, then click Install.

To preview a package's contents before you install it, click the Manifest button.

Modifying the app in a development environment

The app's data source installs sealed. If you deploy the app to a development environment and intend to modify it, unseal the data source so you can edit the app's objects. Leave it sealed in QA and production to preserve equivalence across environments. See Seal or unseal a data source.

Configuration and setup

After you install the app into a new environment, complete the following steps to make it ready to use:

  1. Assign access groups. Add the users who will configure the app to the Registration Portal Administrator group, which grants access to all setup and management. Add App Builder's anonymous user to the Registration Portal Anonymous group, which lets unauthenticated visitors reach the register, login, and password-recovery pages. See Security and access.

  2. Set the security provider. In the Parameter settings, update the ProviderId value to match your environment's authentication host. For how to create this provider, see Create the Application Authentication security provider.

  3. Set the default identity. Set the DefaultIdentityName value to a valid security context in your host environment. New accounts are provisioned against this identity. To set up the generic user account it maps to, see Configure a generic user account; for how the identity governs access, see Security and access.

  4. Review security policies. Verify the lockout thresholds, lock periods, and password complexity settings in the Lockout Policy, Password Policy, and Environment Settings panels. The app installs with these defaults:

    • Lockout Policy: IP Attempts 50, IP Duration 60 minutes, Email Attempts 10, and Email Duration 5 minutes.

    • Password Policy: Minimum length of 8 characters, requiring at least one uppercase letter and one number.

  5. Customize templates. Edit the email subjects, message content, and terms-of-service copy in the Template records.

Security and access

Registration Portal uses App Builder role-based security with two access groups:

  • Registration Portal Anonymous: Grants unauthenticated visitors access to the register, login, and password-recovery pages. Assign App Builder's anonymous user to this group so these public entry points are reachable.

  • Registration Portal Administrator: Grants full access to the app's setup and management, including policies, templates, and the user grid. Assign the users who administer the app to this group.

The app provisions accounts using a semi-anonymous pattern. New users are assigned a baseline identity defined by the DefaultIdentityName setting in the Parameter table. Once a user authenticates, that mapped identity governs what they can access. Administrators can elevate or change a user's access from the management grid.

Anonymous visitors are limited to the registration, login, and password-recovery entry points and the terms-of-service page. The app applies several security controls, implemented as business rules:

  • Lockout by email address and by IP address, using thresholds configured in Parameter.

  • Account-harvesting protection: Login failures return a generic message, and registration and recovery return generic feedback, so the app does not reveal whether an account exists. When someone tries to register with an email that already has an account, the registrant sees the same generic confirmation, but the app emails the existing account holder about the registration attempt, so they can log in to their account or ignore the message if it was not them.

  • Verification-code expiry: Codes expire after a configured window, and issuing a new code invalidates the previous one.

Business rules

Registration Portal's logic is implemented as App Builder business rules. Rule names follow App Builder's Target (Purpose or Subtype) Descriptor convention, so the leading word identifies the table the rule acts on.

Login and lockout rules

Rule Purpose
LoginAttempt (Validation) Email Address Lockout Halts login when failed attempts for the email exceed the configured threshold.
LoginAttempt (Validation) IP Address Lockout Halts login when failed attempts from the IP address exceed the configured threshold.
Session (Validation) Valid Email and Password Validates credentials and returns a generic failure message to avoid revealing account details.

The lockout validations use two supporting subqueries, Count Email Attempts and Count IP Attempts, which count failed attempts within the threshold window defined in Parameter.

Registration and identity rules

Rule Purpose
User (Validation) Duplicate Email Checks for an existing email during registration without revealing whether it exists.
User (Update) Default Identity Name Assigns the default identity to a new account on registration.

Two-factor rules

Rule Purpose
User (Validation) Email Verification Code Expired Determines whether a verification code has passed its expiry time.
User (Update) Email Verification Code Issues a new verification code and invalidates any earlier code.

Troubleshooting

A user is locked out of login

  • Symptom: A user cannot log in and receives a lockout message, even with the correct password.

  • Possible cause: Failed login attempts for that email address or IP address have exceeded the lockout threshold configured in Parameter.

  • Resolution: Wait for the configured lock period to elapse, or have an administrator adjust the thresholds in the Lockout Policy settings.

The login error does not say what was wrong

  • Symptom: A failed login returns a generic message instead of stating whether the email or the password was incorrect.

  • Possible cause: This is expected. To prevent account harvesting, the app returns a generic failure rather than confirming which value was wrong.

  • Resolution: No action is required. Advise users to confirm both their email and password.

A verification code is rejected as expired

  • Symptom: A user enters a registration or recovery code and it is rejected as expired.

  • Possible cause: The code passed its expiry window, or a newer code was issued, which invalidates the previous one.

  • Resolution: Request a new code and use the most recent one.

For further help, review your App Builder logs and contact Jitterbit support.