Security in Jitterbit API Manager
Introduction
This page describes the different ways in which you can secure an API Manager API. These features allow you to configure and manage desired levels of security for various use cases within API Manager:
For information on security features within Jitterbit's system architecture, see Jitterbit security.
Security profiles
An API is anonymous and publicly accessible by default at the time it is created, unless a security profile is configured within API Manager's Security Profiles page and is assigned to the API.
An API security profile governs and secures the consumption of APIs. Security profiles allow a published API to be consumed only by a specific API consumer or a group of consumers. Security profiles can be created and assigned by an organization member having a role with Admin permission.
Harmony organization administrators can require that security profiles be assigned to each API at the time it is created using a setting in the Harmony organization's policies.
Security profile authentication types
Authentication options in security profiles control the access to an API by API consumers. These are the available security profile authentication types:
| Authentication Type | Description |
|---|---|
| Anonymous | Anonymous authentication allows the API to be publicly accessible without requiring any authentication. |
| Basic | Basic authentication uses HTTP authentication to provide API access. When using basic authentication, consumers include the username and password in an encoded string in the authorization header of each request made. |
| OAuth 2.0 | OAuth 2.0 authentication uses one of Microsoft Entra ID, Google, Okta, or Salesforce as the identity provider. When using OAuth 2.0 authentication, the consumer must validate their identity provider credentials to access an API at runtime. For more information on configuring an API identity provider, see API identity provider configuration. |
| API Key | API key authentication uses a key-value pair to access an API. |
Note
Security profiles are cached on the API gateway, so changes to the security profiles of an already-active API can take several minutes to take effect.
Use multiple security profiles
You can use multiple security profiles to employ different methods of authentication and security options in the same environment, with each targeting for a specific group of API consumers.
For example, if you have two types of consumers (accounting and finance), and two APIs (API-Revenue and API-Budget) in an environment and API-Revenue is intended for accounting consumers and API-Budget is intended for both accounting and finance consumers, you can create a single security profile for accounting consumers and assign it to both APIs. You could then create a separate security profile for finance consumers and assign it to API-Budget.
The result of the two security profiles is that accounting consumers (using their security profile) can only access API-Revenue, and finance consumers (using their separate security profile) can access either API-Revenue or API-Budget.
A mix of different authentication types for an API are not allowed unless using one of the specific combinations listed below. Instead, create separate APIs to serve different groups of API consumers.
These security profile combinations are allowed:
- You can assign multiple security profiles with basic authentication to a single API.
- You can assign multiple security profiles with API key authentication to a single API.
- You can assign a combination of security profiles that use basic and API key authentication to a single API.
Any other security profile combination is not allowed.
Use rate limits
Each organization has two allowances, as stated in the organization's Jitterbit license agreement:
- An API hits per month allowance is the total allowance provided to an organization in a month. All calls received by all APIs (in all environments) in a single month count toward this limit.
- An API hits per minute allowance is the maximum rate at which an organization's allowance can be consumed.
By default, an environment or security profile can access an organization's total allowance for hits across all APIs within a minute.
Once an organization has used up its hits per month allowance, then all APIs within the organization will receive an Error 429 until the allowance resets to their max allowance on the first day of following month.
You can use rate limits at the environment and security profile level to enforce a shared maximum number of API hits per minute that can be made across all APIs within an environment to which a security profile is assigned. If the defined rate per minute limit at the organization, environment, or security profile level is reached, the API call is rejected by the API gateway and an Error 429 message is returned. Any underlying operation or third-party API is never called.
Note
Rate limiting is enforced at the organization level, environment level, and security profile level. It is not enforced at the API level.
This table provides examples of ways in which security profiles and environments can be used to enforce rate limits:
| Allowances | APIs in an Organization | APIs in an Environment | APIs in a Security Profile | Usage | Result |
|---|---|---|---|---|---|
Organization: 25 hits per minute Security Profile: 5 hits per minute | 10 | 5 | 5 | 1 hit per minute on each API assigned to the security profile. | As the limit for the security profile (5 hits per minute) is reached, any additional hits to any API assigned to the security profile within the minute are rejected and an Error 429 message is returned. 20 hits per minute are available across the 5 remaining APIs in the organization. |
Organization: 30 hits per minute Environment: 10 hits per minute Security Profile: 6 hits per minute | 15 | 7 | 5 | 5 hits per minute on both of the APIs not assigned to a security profile within the environment. | As the limit for the environment (10 hits per minute) is reached, any additional hits to any of the 7 APIs in the environment within the minute are rejected and an Error 429 message is returned. 20 hits per minute are available across the 8 remaining APIs in the organization. |
Organization: 10 hits per minute Security Profile: 5 hits per minute | 10 | 10 | 1 | 2 of the APIs not assigned a security profile receive 5 hits per minute each. | As the limit the organization (10 hits per minute) is reached, any additional hits to any API in the organization within the minute are rejected and an Error 429 message is returned.Note The organization allowance takes precedence over any limit set within a security profile. |
Note
Attempts against invalid URLs that return Error 404 are not counted against any of the limits or allowances.
For more information on configuring rate limits, see Environments and Security profile configuration.
Use trusted IP ranges
By default, a security profile does not limit access to any predetermined range of IP addresses. You can limit access to the APIs within a security profile to consumers from a single IP address or a range of IP addresses during security profile configuration.
When a consumer attempts to access an API with a security profile that is limited to a certain IP address or a range of IP addresses, the consumer's IP address will be checked against the allowed ranges. IP addresses that do not meet the criteria are rejected and an Error 429 message is returned.
For information on creating and using trusted IP groups, see these resources:
SSL only mode
Any API can be configured to use SSL encryption. By default every API supports both HTTP and HTTPS transfer.
The SSL Only option allows you to forward HTTP traffic to ensure all communication is encrypted. 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).
You can enable the SSL Only option during the configuration of a custom API, OData service, or proxy API.
API Logs
For every hit on an API, the security profile used to access the API is recorded in a log. The API Logs page displays a table of all API processing logs as well as debug logs (if debug logging is enabled) to provide publishers and consumers help in troubleshooting related issues. Logs display for custom, OData service, and proxy APIs when they are called through the cloud API gateway or a private API gateway.