Inbound rules apply to the request. For each rule, you specify an expression to define the condition in which it applies. In most cases, if you don't enter an expression, the rule will apply to all requests. All expression fields accept the SnapLogic Expression Language and API Manager functions.

Validation

Validation rules include:

• Inbound TLS: Verifies the client's TLS certificate with a Groundplex truststore. This rule applies only to requests routed to Groundplexes.
• CORS Restriction: Sets the appropriate headers for browser-based requests so that the browser doesn't block the response. This rule doesn't apply to non-browser based applications.
• IP Restriction: Restricts access based on the client IP address where the request originated. If the request doesn't meet the configured requirements, it is rejected with a 403 Forbidden error.
• Authorized Request Validator: Performs generic validation steps on requests after authorization and returns customized responses. You can use this rule independently or with Early Request Validator rule. For example, if a Task requires a particular HTTP header in a particular format, this rule can validate it before incurring the cost of executing a pipeline.
• Early Request Validator: Performs generic validation steps on requests before authentication and returns customized responses. You can use this rule independently or together with the Authorized Request Validator rule rule. For example, if a task requires a particular HTTP header, this rule can validate the header before incurring the cost of executing the pipeline. Although both rules have the same configuration options, they execute at different times:
• JSON Validator: Validates a request against a JSON schema. You can specify limits on various JSON structures, such as arrays and strings. This capability minimizes the risk posed by content-level attacks. The rule applies only to requests with the Content-Type set to application/json.
• SQL Threat Detector: Protects against SQL commands injected in the header, path, query, and payload of incoming HTTP requests. Malicious requests can contain commands like CREATE TABLE and DROP TABLE that can trigger unwanted modifications or denial of service (DOS) in backend databases. This rule specifies regular expressions (regex) to identify SQL commands, elements, strings, and non-database conformant characters to prevent execution of potentially harmful requests.
• XML DTD Validator: Validates a request against an XML Document Type Definition (DTD) schema. You can upload an XML DTD schema file in the Policy dialog as a valid Swagger XML document. If the request contains a path, parameter, or object that isn't defined in the DTD schema, the client receives a Schema Validation Failed error.
• XML XSD Validator: Validates a request against an XML Schema Definition (XSD). You can upload an XML XSD file in the rule dialog as a valid Swagger XML document. If an invalid path or parameter or object is not defined in the schema, the client receives a Schema Validation Failed error.

Authentication and authorization

Authentication verifies the identity of the caller and authorization determines which resources they have permission to access. You need to configure both types of rules. Unless basic authentication applies, a request that doesn't satisfy authentication returns a 401 error code. If no authorization rule is defined or the requestor isn't authorized, the request returns a 403 error code. APIM 3.0 offers the Authorize by role rule to handle authorization and rules that support the following authentication methods:

Authentication rules run first, followed by Authorization by Role. Authentication rules, with the exception of Anonymous Authenticator, must have a user ID and a role to pass to the Authorization by Role rule.

You can associate an Account with Authentication rules to provide a password, key, or token. The following authentication rules are available:

Authentication rules include:

• Anonymous Authenticator: Allows anonymous access based on a role. This rule identifies the requester by the client IP address, and assigns a role. You must configure the Authorize By Role rule to authorize that role. Because the Anonymous Authenticator Rule allows anyone to access an API, consider combining this rule with a Client throttle rule to avoid overloading a Snaplex with too many requests.
• API Key Authenticator: Authenticates a client with API keys passed in the header or as a query parameter.
• Callout Authenticator: Authenticates the client by calling out to a REST service that validates a token and retrieves information about the user. This rule is an alternative to the other authentication policies.
• OAuth2 Client Credential: You can use this rule to authenticate clients with an OAuth 2.0 token. This implementation is based on the Client Credential flow from Okta.
• Generic OAuth2: Authenticates a client by delegating the authentication to an OAuth2 provider. This rule authenticates requests that don't contain credentials for other authentication policies, such as an API Key. The Snaplex redirects the request to the OAuth provider to start the authentication flow. Successful authentication returns an access token that the rule uses to perform one or more requests to get information about the client, such as the ID and assigned role. Finally, a session cookie is returned to the client, and the client is redirected back to the requested URL. Subsequent requests authenticate based on the session cookie instead of repeating the OAuth flow. This implementation is based on the authorization code flow from Okta and supports OpenId Connect providers.
• JWT Validator: Authenticates requests with a Java Web Token (JWT) token. When you apply this policy, Service consumers must use their JWT credentials to sign their JWT. Before allowing API access to the consumer, the policy does the following:

The built-in authentication rules offer flexibility:

• You can connect to an OpenID Connect (OIDC) implementation through Generic OAuth2 rules. You can create multiple policies with Generic OAuth2 rules if you have multiple IdPs.
• OAuth: You can configure the Generic OAuth2 rules manually to handle API calls. If you don't rely on OAuth2, you can also set up authentication to work manually by calling a REST service to authenticate the user. API Composer also supports machine-to-machine authentication through the Client Credential rule.

With the ID and role returned by an authentication rule, use the Authorize by Role rule: Authorizes a request based on the role associated with the client. Authentication rules validate the caller's identity and this rule authorizes access based on their role. If the caller's role isn't defined in this rule, the Snaplex rejects the request with a 403 Forbidden error.

Shape rules

Shape rules limit requests and configure retries and redirects.

Shape rules include:

• Client Throttling: Limits the number of requests allowed from a client during the specified time period. Applying this rule can help protect a Snaplex from being overloaded by too many requests. The Client Throttling rule rule records the count and rate of requests from individual clients. It compares the values against those specified in the Service Tiers settings. When a limit is met, the client's ability to make requests is throttled for some amount of time—queuing the request for a short period of time, or rejecting the request with a 429 Too Many Requests error. If the request is rejected and the client supports the Retry-After HTTP header, the client can retry the request after the specified number of seconds.
• HTTP Retry: Defines retry logic for external requests to improve the experience of external endpoint consumers. External endpoints can reject requests when resources are unavailable. This rule retries the request on behalf of the client.
• Request Size Limit: Restricts requests based on the size of their content.
• HTTP Redirect: Manages HTTP redirection. When an HTTP response contains a 3xx HTTP status code, the client side handles the redirect as defined in the rule.

Transform rule

The Request Transformer rule: Transforms request headers before being passed to other authorization and authentication rules and request execution.