Logical security and architecture of Jitterbit Harmony

Introduction

Logical security is composed of all the security measures taken within the Harmony platform. This section describes the following:

• System architecture
• Development processes
• Authentication, permissions, and access
• Data storage
• AI services
• iPaaS security topologies

System architecture

Harmony is a unified low-code platform offering iPaaS to integration systems, API management to expose those integrations as APIs, low-code application development to build web and mobile apps, and EDI processing for business-to-business transactions.

The core components of Harmony are infused with AI capabilities, including AI-powered assistants for app and connector building.

The following sections describe the architecture and security of each core component: Low-code designers, Reusable assets, Microservices, and Platform engines.

Low-code designers

Jitterbit's low-code designers are the front-end Jitterbit applications that enable users to create and manage integration projects, APIs, custom web apps and native mobile apps, and EDI processes.

Communication between Jitterbit applications and the Harmony platform happens through Jitterbit microservices. All users must be authenticated with Harmony and all communication is transmitted securely over HTTPS.

User access to Jitterbit applications is further controlled by a combination of organization role permissions and environment access levels, as described in Authentication, permissions, and access.

Integration designers

Either Integration Studio (recommended) or Design Studio can be used for creating, configuring, deploying, and testing Jitterbit iPaaS integration projects:

• Integration Studio is a Harmony portal web application.
• Design Studio is a desktop application that must be installed on a Windows or macOS workstation with Internet access.

Communication through corporate proxy servers is fully supported, as well as IP allowlisting (whitelisting) to ensure corporate VPN adherence if required.

Both applications use the Harmony platform and leverage Harmony security features including single sign-on, user roles and organization permissions, and environment access levels.

A Harmony user's role must have a minimum of Read access in an environment to access projects in Integration Studio or Design Studio. Higher levels of environment access grant additional privileges (see Authentication, permissions, and access).

API Manager

API Manager is a Harmony portal web application where users can create, control, and consume custom APIs, OData services, and proxy APIs.

Jitterbit provides a range of options for securing APIs:

• Security profiles allow a published API to be consumed only by a specific API consumer or group of consumers. You define the authentication method in the security profile, choosing from anonymous, basic, OAuth 2.0, or API key authentication.

• SSL-only mode restricts HTTP traffic to encrypted communications. The identity of the HTTPS URL is verified by Symantec Class 3 Secure Server SHA256 SSL CA. The connection to the HTTPS URL is encrypted with modern cryptography (with TLS 1.2 encryption, the connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism).

• API logs record the security profile used to access the API for each API request.

A Harmony user's role must have either Admin organization permission, or must have a combination of Read organization permission with a minimum of Read access in an environment to access API Manager.

The API Portal for individual APIs or API groups can also be accessed by external users invited by a Harmony organization administrator.

App Builder

App Builder is a low-code visual application builder for creating enterprise-grade web and mobile applications.

Access to a configured App Builder instance is available through the Harmony portal. A Harmony user role with the Admin organization permission is required to configure access by users with a Harmony user role of at least Read permission.

Within App Builder, the following additional security options are supported:

• HTTPS: When HTTPS is enabled, cookies are set with the Secure flag. This prevents the browser from transmitting the cookie across an unsecure (HTTP) channel. Cookies are set with the HttpOnly flag by default. The HttpOnly flag mitigates Cross-Site Scripting (XSS) attacks.

• Single sign-on (SSO): Authentication can be delegated to an SSO provider. App Builder supports various industry standards, including SAML SSO and WS-Federation. These use the PKCS #1 digital signature specification with SHA-256 digests.

• Claims-based authentication: User authentication providers pass claims into App Builder. Security administrators map the claims to user attributes, including group membership.

• Local authentication: Local authentication can be used to authenticate with a password stored in App Builder using the PBKDF2 key derivation function with the SHA-256 hash algorithm, a key length of 16 bytes, a salt length of 16 bytes, and 10,000 iterations. Security features include password policies, password expiration, account lockout, and password reset.

• Sessions: Session storage policies are configurable. By default, App Builder persists session information to the database. Administrators can view sessions and forcibly sign out user sessions. Tracking sessions guards against certain vulnerabilities, such as cookie-replay attacks.

• Roles-based security: Access to data can be controlled with a user's group membership, which determines the user's roles, which determine permissions to business data. Realms allow administrators to delegate administrative tasks such as user provisioning and group membership.

EDI

EDI is a Harmony portal web application for managing EDI trading partners and the transactions made with them.

The EDI app processes EDI data in the Harmony cloud. (Jitterbit provides a separate offering for on-premises processing of EDI data.)

Personally identifiable information (PII) is masked by default. A Harmony administrator can expose the PII data in the EDI app for up to 24 hours, after which it will again be masked.

The EDI app also provides the option to manage a trading partner's PII by removing it from partner documents.

A Harmony user role with either Read or Admin organization permission provides access to edit and perform all actions in the EDI app. User roles with Read permission also have access to edit and perform actions in pages other than the Admin page.

Marketplace

Marketplace is a Harmony portal web application that provides access to more than 400 integration recipes and process templates that can be imported into an environment to use as a basis for Integration Studio integration projects.

A Harmony user role with either Read or Admin organization permission provides access to recipes and templates in Marketplace. Starting a recipe or template in an environment requires Write access in that environment.

Management Console

Management Console is a Harmony portal web application for managing and monitoring your Harmony organization across the Harmony portal, as well as the components of the Harmony platform itself.

Management of the organization includes configuration of organization policies, including single sign-on (SSO), and definition of who can access different areas of the Jitterbit applications (see Authentication, permissions, and access).

The Management Console facilitates a variety of other management tasks that are typical of a Harmony administrator:

• Set up environments, agents, and agent groups for use with Integration Studio or Design Studio integration projects.
• Manage schedules, variables, listeners, and backups for integration projects.
• Manage external user access to the API Portal.
• Configure access tokens for connecting the EDI app to Integration Studio.
• Add message queues to be used with Integration Studio.

The Management Console also provides information for monitoring the organization:

• Audit logging information about who and what activity took place in the organization.
• Operation logs and deploy history for Integration Studio and Design Studio integration projects.

A Harmony user role with Read organization permission has access to the Dashboard page, while the Admin organization permission has access to and the ability to make edits and perform actions on all Management Console pages.

A user role with Read organization permission can access additional Management Console pages when granted environment access levels as described in Authentication, permissions, and access. The access control layer model defined for each environment is granular, such that the configurations users see and can interact with depends on the user's access controls. Access controls are applied to all functions, including searching for operations, running operations, viewing logs, etc.

Data Loader users have access to limited information on the Dashboard, Runtime Operations, and Agents pages.

Reusable assets

Reusable assets include connectors, applications, and integration projects and the tools to build them:

• Connector SDK: The Jitterbit Connector SDK (software development kit) provides the means for developers to build connectors and make them available in Integration Studio.
• Connector Builder: Jitterbit Connector Builder is a low-code wizard for anyone to create an Integration Studio connector that exposes a REST API accessible through HTTP.
• Pre-built connectors: Jitterbit and its partners provide hundreds of pre-built Integration Studio connectors for use in integration projects.
• Pre-built applications: Jitterbit offers pre-built web and native mobile apps through App Builder.
• Templates: Pre-built bidirectional integration solutions that solve a complex use case are provided through Marketplace.
• Recipes: Unidirectional integration projects that solve a simple use case are provided through Marketplace.

Microservices

Jitterbit applications communicate with the Harmony platform through a well-defined set of Harmony platform APIs referred to as Jitterbit's microservices.

The APIs are created using the same secure coding rigor as Harmony itself (see Development processes).

All users of these APIs must be authenticated with Harmony and all communication is transmitted securely over HTTPS.

Platform engines

The Harmony platform provides all the infrastructure and services to deploy, manage, and run integration projects; build custom web and native mobile apps; create, control, and consume APIs; and process EDI transactions.

API gateways

An API gateway is a service that enforces the policies and security profiles created on APIs using the API Manager web application. Connectivity to APIs published through API Manager is enabled through either Jitterbit's cloud API gateway or a private API gateway.

The API gateways handle these security tasks involved in accepting and processing calls made to an API:

• Traffic management
• Authorization and access control
• Rate limiting
• API payload processing

Security features are configured at the API level or security profile level and are cached on the API gateway, which are then referenced during API runtime.

Jitterbit's cloud API gateway is managed, maintained, and hosted by Jitterbit and does not require any configuration.

A private API gateway is a local gateway for processing APIs directly from your own servers. A private API gateway can be restricted solely to an internal network behind a firewall and not be accessible from the Internet, though certain Jitterbit services must be allowlisted (whitelisted). With a private API gateway, API response payloads never pass through Jitterbit's systems.

Messaging

Communication among various Jitterbit iPaaS components, such as Integration Studio, agents, and the Harmony platform, is achieved by using a set of secure runtime messaging services based on the Java Messaging Services (JMS) API included in the Java Platform. These APIs are internal to Harmony, and customers do not have any access to these APIs.

Agents include listeners to the JMS messaging service. All agents that listen for requests strongly authenticate and are provided an authorized session in the Harmony messaging network. They can only listen to requests for their particular agent groups or that are made to them directly via Harmony. Messages are never sent to agents; agents always pick them up over HTTPS. This enables agents to run behind corporate firewalls and to remain protected without the need for opening ports that would allow incoming traffic from the Internet.

Agents

The integration processes designed in Integration Studio and Design Studio projects are run on agents, using either a Jitterbit cloud agent group or private agents and a private agent group.

These processes can be run completely in the cloud without the need to procure or manage any software or the infrastructure required to operate it. Those who choose to deploy agents either on-premises or in a hybrid mode have the flexibility to run their integration processes by deploying private agents behind the firewall, thereby obtaining greater control on where their data flows.

Jitterbit recognizes that customers have a need for their integration processes to communicate with applications that operate behind corporate firewalls for various security and regulatory compliance reasons.

Harmony's system architecture caters to both scenarios: integration processes can run completely in the cloud or can run behind corporate firewalls to ensure that business data does not get exposed to the cloud. Users can also employ hybrid models where some integrations run in the cloud such as development and others for example in production can run behind corporate firewalls.

While the system simplifies the provisioning, deployment, and management of integration projects it also offers users the flexibility to run their integration operations using detachable private agent groups. These are self-contained subsystems that can be installed behind corporate firewalls or on dedicated private clouds.

The separation of integration designs, which are stored on Harmony, from integration runtime that occurs on agent groups, enables customers to control access and flow of sensitive business data.

Cloud agent group

Cloud agents are services, known as backend as a service (BaaS), designed to process and service client needs on an ad-hoc basis. They perform all of their work in an event-driven fashion, thereby eliminating the need for any setup, configuration, or management that is traditional with "always-on" server systems that sit behind applications.

Jitterbit provides its customers the option to run all their integrations in the cloud by providing a scalable, fault-tolerant, clustered agent group fully maintained and managed by Jitterbit.

To enhance security and protect privacy, Jitterbit cloud agents are coded to ensure that locally processed data is not persistent; it is used for the minimal time necessary to complete the intended process, then purged.

When the Jitterbit cloud agent group performs an integration, it will directly connect with the application that requires data integration. It will then read and post data to these applications.

Metadata persisted in the Jitterbit cloud agent group is stored in encrypted Amazon S3 buckets that are accessible only to the agent group.

For customers that need applications to reside within their firewall, or for users that perform integrations under strict regulatory compliance that forbids data to either travel outside a given geographical boundary or reside in the cloud, Jitterbit recommends using a private agent group.

Private agents and private agent group

Jitterbit provides the flexibility for customers to provision and manage their own agent groups and private agents within their corporate firewall or virtual private clouds. This allows customers to choose where their integration runtime environment operates and lets them control which network their business data travels and resides in. By using private agent groups for integrations, companies can ensure that their sensitive business data never flows through the Harmony platform.

Agents belonging to private agent groups authenticate and communicate with Jitterbit Harmony over HTTPS. Private agent groups deployed behind corporate firewalls can be configured to communicate via a corporate proxy server. If your organization does not restrict outbound connections, there are no additional networking requirements, such as opening ports within corporate firewalls. When outbound connections are restricted, you must allowlist (whitelist) certain Jitterbit services.

Private agent code is created with the same coding rigor as Harmony code (see Development processes).

While private agent groups cater for stringent security requirements, the user or customer is responsible for installing and managing their private agents. In the cloud agent group, Jitterbit provides out-of-the-box high availability and scalability on-par with what is expected from a serverless technology. However, in private agent groups, the security and scalability for private agents is a customer responsibility (although high availability is still ensured by the Harmony platform whenever more than one agent is used within a private agent group). Jitterbit provides best practice advice for hosting private agent code in System requirements for Jitterbit private agents.

Listening service

The Listening service is an application service that runs on a private agent and is consumed by certain Integration Studio connectors that have listening capabilities. The listening service provides asynchronous event handling capabilities for operations deployed on the agent.

1. An operation containing a connector configured with an event listening activity is deployed and enabled for listening.
2. The listening service within the agent will start a listener for that operation.
3. The listener will start actively listening for any event notifications from the endpoint.
4. When an event happens at the endpoint, it publishes an event notification that can be received by its subscribers.
5. The listener picks up the event notification message.
6. If there is one agent in the agent group, the listener relays the event message to the operation. If the agent group contains the minimum number to allow full listening service capabilities, the event message is passed to the agent with the least workload.
7. On receiving the event notification, the operation will trigger a downstream operation.

Transaction logs

Transaction logs, also referred to as operation logs, are the logs generated when an Integration Studio or Design Studio operation is executed. They contain information about the operation, including its location, timeframe, and status.

Cloud logging determines if log data is temporarily saved and accessible from the Harmony cloud. When cloud logging is enabled, the logs for operations also include detailed log messages. Cloud logging is always enabled for Jitterbit cloud agent groups and can optionally be disabled for private agents.

Operation logs, including detailed log messages from both cloud agents and private agents, and component input and output data within operation logs, are retained for 30 days.

Design repository

Jitterbit stores all projects deployed to Harmony in a multi-tenant design repository. This project repository is built on a multi-tenant database architecture, which provides logical partitioning of projects by organization and, in most instances, by environment. Specifically, Harmony isolates and secures customer projects using the following:

• Secure database architecture: Includes separated database and separated schema architecture.
• Secure connections or tables: Uses trusted database connections.
• Encryption: Obscures critical data so that data remains inaccessible to unauthorized parties even if they come into possession of it.
• Filtering: Uses an intermediary layer between a tenant and a data source that acts like a sieve, making it appear to the tenant as though its data is the only data in the database.
• Access control lists: Determines who can access data in the application and what they can do with it.

Projects typically contain credentials such as username and password used to connect to various endpoints. This information is encrypted within the multi-tenant repository.

The repository is replicated across two regions (such as East and West) for each Harmony region (NA, EMEA, and APAC).

Customers do not have any direct access to this repository. The various Jitterbit iPaaS components, such as integration designers and cloud agents, use APIs to access the repository. Once authenticated and access control is validated, all communication with the repository is done through various API layers. In addition to controlling edge API access via HTTPS and server-side sessions, APIs must validate user access control through environment-based and Role-Based Access Control (RBAC) lists. These lists ensure that users can view, act upon, and change the system based only on the permissions granted by an organization administrator (user with Admin permission). In addition, audit trail granularity is configurable per customer.

The Harmony rotating activity database stores runtime status information as well as logs of running operations of all Harmony users.

The activity database is built on a multi-tenant architecture, and while activity data for all users resides in the same database, there is logical segmentation by organization and environment applied through a software access control layer and unique encryption keys to ensure that users can view only the activities that they have access to.

The activity database is replicated across AWS Regions and Availability Zones to ensure high availability and is backed up if there is a need for it to be restored.

Access to the activity database is provided by a set of APIs. The activity log uses similar APIs and access control list (ACL) infrastructure as the project repository.

File services

Harmony includes a set of file services used to store files, such as schemas, and customizations. All files are stored in AWS S3 service and can be accessed only through the Harmony platform and cannot be accessed directly.

Schema repository

To support integrations from a variety of endpoints, Harmony stores various types of schemas, such as WSDL, XSD, JTR, and DTDs.

In addition to storage in the Harmony cloud datastore, Integration Studio schemas are stored in the design repository to manage reusability of schemas within a project.

Customizations repository

To support integrations from a variety of database endpoints, Harmony stores various JDBC and ODBC drivers, including those that customers install on private agents themselves.

To extend the capabilities of Integration Studio, you can build your own custom connectors using Connector Builder or the Connector SDK.

Backend services

Backend services are Harmony's underlying services and APIs through which all data flows.

Backend services handle tasks such as logging in, user management, deploying, scheduling, organization management, etc.

Application builder runtime

App Builder solutions can run in the following deployment configurations:

• On-premises: The App Builder environment is deployed on-premises at the customer site. The web and database servers and the App Builder environment all reside on customer hardware in the customer network. This option provides full control and flexibility over the App Builder environment and infrastructure. All maintenance, security, hardware, and software operations are managed by the customer.

• Private cloud: The App Builder environment is deployed on a customer private cloud provider, either AWS, Google Cloud Platform (GCP), or Microsoft Azure. The web and database servers and the App Builder environment all reside in the private cloud. This option provides flexibility and control over the App Builder environment and infrastructure. All maintenance, security, hardware, and software operations are managed by the customer.

B2B runtime engine

EDI transactions are processed through the EDI cloud runtime, also referred to as eiCloud.

Once a transaction is generated, it is stored in the transaction database while waiting for processing. The EDI document persists until it is archived using the archive settings set for the trading partner. The status of an EDI document can be checked at any time through the EDI Transactions page.

Standard EDI communication protocols are supported, such as FTP/SFTP, HTTP/HTTPS, AS2, custom pipes, etc.

Standard EDI formats are supported, including ANSI X12 (including VICS), EDIFACT and its subsets, and xCBL standards.

Messaging system

The Message Queue (MQ) Service is a cloud-based, multi-tenant messaging queue service for creating and managing queues and messages. It enables you to create integrations that are decoupled from the endpoints you are integrating. The MQ Service is used with the Integration Studio Jitterbit MQ connector.

1. Data is retrieved from a source endpoint, such as by using an Integration Studio connector. The retrieved data can then be transformed into a message to be consumed by the Jitterbit MQ connector.

2. Using the Jitterbit MQ Send or Send Bulk activity, the data is sent to the Jitterbit Message Queue service (which sends the messages to the specified message queue).

3. Messages can then be retrieved from a message queue using a Jitterbit MQ Get or Get Bulk activity.

4. Data retrieved from a message can then be used as input to be consumed by a target endpoint, such as by using an Integration Studio connector.

5. Once the data is consumed, the message can be either acknowledged (using the Acknowledge activity) or negatively acknowledged (using the NACK activity). If the message is not acknowledged or negatively acknowledged before the timeout of 30 minutes, the message will be available to be retrieved from the queue again by either a Get or Get Bulk activity.

Analytics and logging engines

The Harmony platform provides analytics and logging information that can be accessed through the Harmony portal or directly on private agent servers.

Development processes

Jitterbit develops and improves its applications by using sound software-development lifecycle (SDLC) practices such as:

• Identifying vulnerabilities from outside sources to drive change and code improvement.
• Applying hardware and software patches. Our virtual environment allows us to apply code changes and hardware patches without any downtime.
• Providing secure authentication and logging capabilities.
• Removing development accounts, IDs, and passwords from production environments.
• Adhering to strict change management practices for code updates as well as patches.
• Separating test and development environments from production.
• Maintaining separation of duties between development and support staff.
• Ensuring that Personal Identifiable Information (PII) is not used in test environments.
• Removing test and development IDs before migrating code to production.
• Performing regular code review.
• Documenting code changes.
• Engaging senior developer input and approval for all code changes.
• Completing functionality and regression testing before release to production.
• Maintaining backout procedures to preserve high availability and integrity.
• Following secure coding practices according to an SDLC policy and addressing the security training needs for the development team.
• Checking for security flaws as prescribed by the Open Web Application Security Project (OWASP), such as injection flaws, buffer overflows, cryptographic errors, error handling, etc.
• Assessing for vulnerabilities on every release.
• Conducting annual penetration testing.

Authentication, permissions, and access

Before a user can start their work, they must authenticate with Harmony using their user account. That account has role-based permissions in the Harmony organization. Those roles can be assigned various access levels in individual environments.

Registration and authentication

In order to access and use the Harmony platform, a user must register and authenticate using their user account.

Password strength, complexity, and attributes, such as two-factor authentication, are customizable so that customers can match the requirements of their security policy. Administrators can also restrict access to specified member domains or require that user IP addresses be within a specified range. These settings are set in an organization's policies.

When single sign-on (SSO) is enabled, such requirements are instead managed by the identity provider. SSO is also enabled by an administrator from an organization's policies. Jitterbit supports these major identity providers:

• Autodesk (OAuth 2.0)
• Azure Active Directory (SAML 2.0)
• BMC (proprietary to BMC customers only) (OAuth 2.0)
• Google (OAuth 2.0)
• Okta (SAML 2.0)
• Salesforce (OAuth 2.0 and SAML 2.0)

When SSO is enabled for an organization, users log in to the Harmony portal and Design Studio with the credentials for their configured identity provider.

All communication with Harmony occurs over HTTPS (greater than TLS 1.2).

User roles and organization permissions

Every Harmony user has their own personal, role-based account and login credentials where personal integration tools and projects are stored securely.

Once authenticated, Harmony identifies all the organizations and environments that this user has access to. Harmony provides the user with a list of the assets they can work on and allows the user to create assets in any environment where they have sufficient privileges.

Privileges are role-based and selectable/configurable per environment per organization. Every organization has two default roles:

• Administrator: A role called Administrator whose Admin permission allows access to all assets belonging to that organization.
• User: A role called User whose Read permission provides access to the Harmony portal and other areas of minimal access.

In addition to Admin and Read permission, these independent permissions are available to be assigned to roles:

• Agent-Install: Allows a user to install agents but provides neither control nor visibility outside of this function. This can be used to allow administrators within and outside the company to establish additional connectivity without any impact to the projects or even knowledge of the platform.
• ApiConsumer: When used in combination with environment access levels, provides access to see OpenAPI documentation in an environment. On its own, this permission allows access to the API Portal page.

Administrators can add new roles to the organization and invite other Harmony users to join when they need to work in teams to design, build, test, and manage their projects, APIs, and EDI data. Users can be added to multiple roles within an organization.

Refer to the Permissions table for information about the privileges afforded by each permission, and to Roles for creating additional roles with any combination of permissions.

Environments and access levels

Environments are used to segregate an organization's assets for these Harmony applications:

• Integration Studio and Design Studio integration projects are deployed to environments associated with agent groups.
• API Manager APIs are created and published in environments.
• Trading partners are added and EDI data is processed per environment.

Environments represent a given state of a project or API. Many projects exist in various stages within different environments. For example, a common project lifecycle configuration might have three environments: development, test, and production. A project or API can exist in different states within each environment.

Organization administrators (users with Admin permission) manage access to each environment using role-based access. For example, users in the developer role may have read, execute and write privileges in the development environment, but only read access to the test environment and no access to the production environment.

There are four cascading environment access levels:

• View Logs: Allows a user to view Integration Studio and Design Studio operation logs through the Management Console Runtime Operations page in a particular environment but provides no visibility or control over projects. This lets users support but not modify projects deployed to critical environments such as production. Access is limited to viewing the table of operations and does not include access to log messages.

• Read: Allows a user read-only access to Integration Studio and Design Studio projects and API Manager APIs in a given environment. This can be used to share templates or to allow users to view but not change assets. This access level also provides read-only access to the Management Console Projects, Environments, and Agents pages.

• Execute: Allows users to run Integration Studio and Design Studio operations and view log messages on the Management Console Runtime Operations page within a given environment. This is a common access control for test environments and is often granted to users who need to support projects, as they may need to both test and run tasks as needed.

• Write: Allows full control to a given environment. Users belonging to a role with Write access can make edits and perform actions within that particular environment. This includes deploying Integration Studio and Design Studio operations; editing and publishing API Manager APIs; starting recipes and templates from Marketplace; and performing actions on the Management Console Projects, Environments, and Agents pages.

Data storage

The following sections describe the types of information stored in Harmony.

User data

When a user registers and subscribes to Harmony, they must provide the following information, which is stored in the project repository: first name, last name, email, and phone number. Company, company address, and company website can be provided but are optional.

In addition, certain system data that can be used to identify a user is logged to ensure the security and integrity of the system.

User authentication

Successful and failed login attempts are logged to identify potential security breaches and determine if someone is attempting to gain unauthorized access to the system. This information is recorded:

• User ID: The user ID associated with each login attempt. This helps identify which user is attempting to log in and track their activity.
• Timestamp: The time of each login attempt. This helps identify when a user is attempting to log in and track their activity over time.
• IP address: The IP address associated with each login attempt. This helps identify where the user is attempting to log in from and detect potential security breaches.
• Device information: Information about the device used to log in, such as the operating system, browser version, and device type. This helps identify potential security breaches and troubleshoot any issues that may arise.
• Logout events: Every time a user logs out. This helps ensure that users are logged out and track their activity.

User authorization

User authorization determines whether a user has the appropriate permissions to access a specific resource or perform a specific action within a system.

In addition to User ID and Timestamp (described in User authentication), this user authorization information is logged:

• Resource ID: The ID of the resource that the user is attempting to access or modify. This helps identify which resource the user is attempting to access and track resource usage.
• Action ID: The ID of the action that the user is attempting to perform. This helps identify which action the user is attempting to perform and track action usage.
• Authorization result: The result of each authorization attempt, including whether the user was granted or denied access to the resource or action. This helps identify potential security breaches and track resource and action usage.
• Authorization policies: Information about the authorization policies, such as the name and version of the policy, and any relevant configuration options. This helps troubleshoot authorization issues and audit policy changes.

Data access

Data access refers to the process of reading or modifying data within a system.

In addition to User ID, Timestamp, IP address, and Device information (described in User authentication), this data access information is logged:

• Data ID: The ID of the data that the user is attempting to access or modify. This helps identify which data the user is attempting to access or modify and track data usage.
• Access type: The type of access being attempted, such as read or write. This helps identify whether the user is attempting to view or modify data.
• Access result: The result of each data access attempt, including whether the user was granted or denied access to the data. This helps identify potential security breaches and track data usage.

Configuration changes

Configuration changes refer to modifications made to the configuration settings of a system or application.

In addition to User ID and Timestamp (described in User authentication), this configuration change information is logged:

• Configuration item: The specific configuration item that was changed. This helps identify which setting was modified and track changes to that item over time.
• Old value: The previous value of the configuration item before the change. This helps identify what the setting was before the change was made.
• New value: The new value of the configuration item after the change. This helps identify what the setting was changed to.
• Change type: The type of change that was made, such as an addition, modification, or deletion. This helps identify what type of change was made to the configuration item.
• Reason for change: (optional) The reason for the configuration change, if available. This helps identify why the change was made and troubleshoot any issues that may arise as a result of the change.

System events

System events refer to various events that occur within a system, such as system startup or shutdown, errors, warnings, and other system events.

In addition to User ID, Timestamp, and IP address (described in User authentication), this system event information is logged:

• Event type: The type of event that occurred, such as an error, warning, or informational event. This helps identify the severity of the event and prioritize troubleshooting efforts.
• Event description: A description of the event, including any error messages or other relevant details. This helps identify what happened and troubleshoot any issues that may arise.
• Source of event: The source of the event, such as the application, system process, or device. This helps identify where the event occurred and isolate any issues to specific components of the system.
• Event status: The status of the event, including whether it was resolved or is still ongoing. This helps track the resolution of the event and ensure that all issues are properly addressed.

API usage

API usage refers to the use of application programming interfaces (APIs) to interact with a system or application.

In addition to User ID, Timestamp, IP address, and Device information (described in User authentication), this API usage information is logged:

• API endpoint: The specific API endpoint that was called. This helps identify which functionality was accessed and track API usage by endpoint.
• Request parameters: The parameters that were passed in the API request. This helps identify what data was used in the API call and troubleshoot any issues that may arise.
• Response status: The status of the API response, including any error messages or other relevant details. This helps identify whether the API call was successful or not and troubleshoot any issues that may arise.

Integration project data

To run and manage an integration project, a user must deploy the project to Harmony. The project stores design and implementation details to instruct agent groups what activities they need to perform. This includes the following:

• Integration operations that describe what a unit of integration will do. For example, synchronize all changes to customer data in the CRM system with customer data in the ERP system.
• Transformations and scripts that describe how that data is transposed from the source system to the target system. This includes any validation rules or data manipulation required to transfer the data successfully.
• Interfaces that describe the various source and target object structures. These interfaces can be simple text structures or complex XML, JSON, or EDI object representations.
• Connections and endpoints that are used as sources or targets. While these can be hard-coded values, including system addresses and credentials, they can also be referenced through variables that can be stored in internal databases for customers that implement their own credential vaults.
• Schedules and notifications that determine when batch operations need to run and what to do in the event of successful and failed outcomes.
• API endpoints that inform agents and agent groups how to expose APIs so that external system events can call and invoke Jitterbit integrations.

Persistent data is secured at rest with:

• Authentication
• Access control lists
• FIPS 140-2 encryption and unique per customer encryption keys

Persistent cloud data is secured in transit with:

• Authentication
• TLS (Transport Layer Security) encryption

Integration activity log

When an agent group runs an integration operation, it synchronizes its logs to the Harmony multi-tenant rotating activity log. This includes the following information:

• Status: The state of an operation (e.g. pending, running, successful, failed).
• Agent: Which agent in the agent group ran the operation.
• Timing: When the operation run was submitted, started, and completed.
• Submitted by: Who submitted the request to run the operation.
• Records processed: The number of records processed from the source system and how many records were posted to the target.
• Message: Any additional information that is relevant for troubleshooting a failed outcome, or summary information that a user explicitly tells Jitterbit to write to the log using the internal function WriteToOperationLog.

In addition, when operation debug logging is enabled on an Integration Studio operation, component input and output data is written to the operation log.

The operation log data is stored in the cloud on a rotating daily partitioned system. The activities for each day are captured in that day's partition and each partition is dropped after 31 days. Activity log data older than 31 days is permanently removed.

Operation logs, including detailed log messages from both cloud agents and private agents, and component input and output data within operation logs, are retained for 30 days by Harmony.

Agent logs

Each agent can generate additional data that can either be accessed via Harmony or can be stored on local file storage devices and accessed from within a firewall. These are detailed logs, which include:

• Operation debug logs for cloud agents or for private agents
• Connector verbose logs accessible only on private agents
• Additional logs accessible only on private agents
• Files of successful records processed
• Files of failed records processed

The agent groups and agents do not automatically synchronize these with Harmony, as they typically include confidential business data. By using their own storage devices, customers can secure their data within their firewall or on their own private cloud infrastructures.

These logs are useful for detailed troubleshooting and auditing purposes.

By default, a private agent group will store log files, debug files, temporary files, transformation data, and success and failure files for 1 to 14 days, depending on the configuration of the file cleanup service rules.

Integration test data that flows through Harmony

In addition to data stored in Harmony, business data can flow through the cloud platform during integration design. This non-persistent test data flows when performing functions such as:

• Preview using sample file: Brings sample data – either loaded by the user or mock data created from the source structure – into a transformation to assist a user in identifying elements in an interface and testing transformations. Shows the transformed target result for a given set of data that is loaded.
• Preview using source data: Brings source data from certain endpoints – such as that from a database, Salesforce, or NetSuite query – into the transformation being previewed and shows the transformed target result for a given set of data that is loaded.
• Test script: Allows a user to test scripts including functions that could return data – such as that from a database, Salesforce, or NetSuite query – or scripts that show variable values returned from an API.
• Test query: Allows a user to test whether a query is valid and returns a sample of data from the endpoint during configuration of certain endpoint activities, such as those for a database or Salesforce query.

AI services

The Harmony platform is infused with AI capabilities including AI-powered assistants and chatbots:

Jitterbit uses AI services to process data with these features:

• iPaaS AI Assistant: The Connector Builder AI assistant (Beta) sends anonymized prompts to OpenAI to teach it to understand API documentation that it uses to generate an Integration Studio connector. Jitterbit's AI mapping feature (Beta) is based on Jitterbit's own model. Jitterbit does not send any transformation data to any model providers.
• APIM AI Assistant: The Jitterbit AI Bot (Beta) for API Manager sends anonymized prompts to OpenAI to create and publish assets in API Manager.
• App Builder AI Assistant: The App Builder AI app assistant (Beta) sends anonymized prompts to OpenAI to be used to generate an App Builder application.
• AI Chat Bot: The AskJB AI chatbot uses OpenAI with Retrieval Augmented Generation (RAG) to retrieve public information available through the Jitterbit Documentation site. AskJB AI is available through the Jitterbit Harmony portal and publicly on the Jitterbit Documentation site.

iPaaS security topologies

Any integration project or service, including APIs, can be deployed with the security topologies described below. Depending on the immediate and/or specific environmental needs, you should employ the topology that meets your organization's data requirements and governance policies. These deployment architectures, with associated security topologies, are summarized as follows and detailed in this section.

• Cloud: On the Harmony cloud, where the system and scale are completely managed by Jitterbit.
• Private (On-Premises, Local): On an on-premises server or private cloud, where the system is self-hosted and managed locally.
• Hybrid: In a hybrid mode, where particular portions of the system are self-hosted, and the rest is managed by Jitterbit.

Furthermore, Jitterbit allows any number of combinations and locations for its components, as well as allows swapping the deployment options ad hoc in different situations. This flexibility leads to these benefits:

• Greatest processing performance: Performance can be enhanced by using edge processing, where agents are located next to where the data resides.
• Ease of management: Remote management is available even for private/local deployments.
• Security and privacy: All processing is performed by the agents directly without exposure to outside parties beyond the immediate source and target connections.

Full cloud deployment security topology

Customers who need to perform integrations where all their data sources are accessible via the cloud can deploy their projects to Harmony environments and run their projects on the Jitterbit cloud agent group.

Here, the Jitterbit-operated multi-tenant public cloud agent group will access customer business data directly over the Internet using HTTPS. Jitterbit agents within this agent group will process business data and post it to any required target system. The data will flow within the Jitterbit network using HTTPS.

Customers that have policies that don't allow for cloud utilization or require excessive liability and indemnification guarantees should validate that the Jitterbit Master Subscription Agreement and Privacy Policy comply with needs pertaining to their industry regulations, customer provisions, customer indemnification, and customer liabilities terms.

Hybrid deployment security topology

In a hybrid deployment scenario, particular portions of the system are self-hosted, and the rest is managed by Jitterbit. For example, you may not want to expose databases and apps to any cloud systems, including Jitterbit, if your organization's requirements do not allow for data to reside in the cloud (outside the firewall) due to privacy and regulatory concerns.

In this case, the private agents reside behind the firewall, while the API gateway is in the Harmony cloud. The agent requests the information through the messaging layer and puts the payload from the apps and data sources back to the gateway via payload. Customers can limit what gets stored in the logs to prevent this data from reaching the Harmony cloud.

Private deployment security topology

In most enterprise integration scenarios, the agent group must access both internal and cloud applications. Here, users would deploy their projects to Harmony environments, install their own private agent groups within their networks that have access to their applications, and then manage those agent groups provisioned through the Harmony platform.

This topology enables users to provision and manage their agent groups using Harmony, but the agent group and any sensitive business data that is processed or stored resides within their network. In this topology, the private agent group can run on Windows or Linux physical or virtual server environments (see System requirements for private agents for further information).