Announcing NGINX Plus R22

Announcing NGINX Plus R22

We are pleased to announce that NGINX Plus Release 22 (R22) is now available. Based on NGINX Open Source, NGINX Plus is the only all-in-one software load balancer, content cache, web server, and API gateway. The primary focus of the release is monitoring and authentication, for enhanced granularity and resilience of your applications at scale.

New features in NGINX Plus R22 include:

• Enhancements to client certificate authentication – Online Certificate Status Protocol (OCSP) verification adds a layer of security to check for revoked certificates with mutual TLS.
• OpenID Connect support for multiple IdPs – In NGINX Plus R15, we introduced OpenID Connect (OIDC) integration to enable our customers to add single sign‑on (SSO) to their applications. With NGINX Plus R22, you can easily integrate with multiple OIDC identity providers (IdPs).
• More metrics on the live activity monitoring dashboard – The dashboard now displays metrics about OIDC activity and historical charts of request and connection limiting.
• NGINX JavaScript module enhancements – The NGINX JavaScript module (njs) has been updated to 0.4.1, with several bug fixes and new features such as importing JavaScript modules and accessing raw header objects.

Important Changes in Behavior

• Older operating systems no longer supported –

  • Alpine Linux 3.8 is no longer supported
  • As announced for NGINX Plus R21, NGINX Plus is no longer available on 32‑bit platforms (i386 architecture)

New Features in Detail

OCSP Validation of Client Certificates

NGINX Plus supports mutual TLS, which uses client certificates both to verify the identity of the connecting client and to establish an encrypted connection. Mutual TLS provides a high level of assurance about the client’s identity, but managing revoked certificates can be an administrative burden. The Online Certificate Status Protocol (OCSP) solves this by verifying the status of client certificates as they are presented.

You can configure NGINX Plus to use OCSP to check the validity of X.509 client certificates, as defined by RFC 6960.

To enable OCSP validation of SSL client certificates, include the new ssl_ocsp directive along with the ssl_verify_client directive, which enables certificate verification.

NGINX Plus sends the OCSP request to the OCSP URI embedded in the client certificate unless you define a different URI with the ssl_ocsp_responder directive.

To cache OCSP responses in a single memory zone shared by all worker processes, include the ssl_ocsp_cache directive to define the name and size of the zone. Responses are cached for 1 hour unless the nextUpdate value in the OCSP response specifies a different value.

The result of the client certificate validation is available in the $ssl_client_verify variable, including the reason for OCSP failure.

The TLS handshake fails if the client certificate is not trusted or the OCSP response is not valid. Status code 495 (SSL Certificate Error) is returned and an entry is created in the error log at the error severity level:

YYYY/MM/DD hh:mm:ss [error] 31222#0: *5 certificate status "revoked" in the OCSP response while requesting certificate status, responder: 127.0.0.1

OpenID Connect Enhancements

Our OpenID Connect reference implementation for NGINX Plus extends SSO across new and existing applications to minimize complexity and cost. The reference implementation uses a combination of NGINX Plus features and the NGINX JavaScript module (njs) to perform a code exchange with the authorization endpoint and receive an ID token from the IdP. The ID tokens themselves are cached in the NGINX Plus key‑value store, and an opaque session token sent to the client. Clients then authenticate by presenting a valid session token that NGINX Plus uses to verify the ID token before accessing backend applications.

This release brings numerous enhancements to the OIDC reference implementation, and two significant changes:

1. The configuration now supports multiple IdPs by passing appropriate input variables from inbound requests into multiple map blocks. This additional flexibility reduces the need to modify the OIDC reference implementation code.
2. The JavaScript code is now implemented as a module so that it can co‑exist with other njs solutions on the same host without needing to manage all of the njs code in a single file.

Here’s a sample configuration:

Each map block allows multiple values so that multiple IdPs and auth parameters (Client secret, JWK key file, authorization endpoints) can be supported. Here we use the $host variable as the input parameter, but you can specify any variable derived from the request header.

The NGINX Plus API now tracks activity related to OpenID Connect logins, to help with monitoring and troubleshooting. See the GitHub repository for more information about the OpenID Connect reference implementation.

Real-Time Dashboard Charts for Rate and Connection Limiting

DDoS and brute‑force password guessing attacks are two critical threats to your applications. You can mitigate their effects with rate limiting – having NGINX Plus limit the number of requests each client can make in a certain period of time.

NGINX Plus R20 added real‑time monitoring of request rate and connection limiting to the NGINX Plus API (at the /api/version/http/limit_reqs and /api/version/http/limit_conns endpoints). The information now appears on the NGINX Plus live activity monitoring dashboard, with cumulative counts in table form and time‑stamped counts in chart form:

• Request rate limiting metrics appear in the Limit Req table on the HTTP Zones tab
• Connection limiting metrics appear in the Limit Conn table on the TCP/UDP Zones tab

The table includes a row for each zone defined by a limit_req_zone and limit_conn_zone directive. To display the chart, click on the chart icon at the left end of the row.

The expanded chart updates continuously and shows values for each time interval as a stacked area graph. You can customize the displayed information in the following ways:

• Choose the range of time to display: 1 minute, 5 minutes, or 15 minutes
• Hover over the chart to display the precise counts for a timepoint
• Hover over a statistic type in the legend area to highlight that statistic in the chart
• Click a statistic type in the legend area to toggle between displaying and not displaying it
• Drag the chart left and right to view historical data

At the default dashboard‑update interval of 1 second, each chart stores about 30 minutes of historical data. Increasing the dashboard update interval (updating less often) increases the amount of historical data available. Note that the dashboard charts are not persistent, and historical data is lost when you navigate away from or reload the tab.

Enhancements to the NGINX JavaScript Module

The NGINX JavaScript module extends NGINX Plus functionality to enable a wide range of use cases, including gaining finer control over traffic, consolidating JavaScript functions across applications, and defending against security threats. The NGINX JavaScript module has been updated to 0.4.1 and includes these features:

• The new js_import directive for importing multiple module files that implement location and variable handlers
• Improved header support, including new raw header objects
• You can use TypeScript definition files in your njs code
• Support for converting external values to native JavaScript objects

The following code and configuration illustrates how the new r.rawHeadersIn object can be used to log the exact set of headers sent by the client whenever an error is encountered.

= 400) {
return JSON.stringify(r.rawHeadersIn);
} else {
return ”; // Do not trigger access_log if= condition
}
}[/config] logging.js –>

Here’s a sample log entry for a 404 response:

$ curl http://localhost/bogus
$ tail --lines=1 /var/log/nginx/access_json.log
{"response":{"timestamp":"YYYY-MM-DDThh:mm:ss+TZ_offset","status":404},"request":{"client":"127.0.0.1","uri":"/bogus","headers":[["Host","localhost:80"],["User-Agent","curl/7.64.1"],["Accept","*/*"]]}}

Delay on Authentication Failure

To mitigate against timing attacks such as password brute‑force attacks and credential stuffing, you can have NGINX Plus delay its response when authentication fails. The new auth_delay directive specifies the delay, which can be applied to authentication requests processed by the Auth Basic, Auth JWT, and Auth Request modules.

Upgrade or Try NGINX Plus

If you’re running NGINX Plus, we strongly encourage you to upgrade to NGINX Plus R22 as soon as possible. You’ll also pick up several additional fixes and improvements, and it will help NGINX to help you when you need to raise a support ticket.

If you haven’t tried NGINX Plus, we encourage you to try it out – for security, load balancing, and API gateway, or as a fully supported web server with enhanced monitoring and management APIs. You can get started today with a free 30-day trial. See for yourself how NGINX Plus can help you deliver and scale your applications.

The post Announcing NGINX Plus R22 appeared first on NGINX.

Source: Announcing NGINX Plus R22