PingFederate 10.1 - June 2020 - PingFederate - 10.1

Enhancements

Administrative console and API

A new delightful experience

The use cases and standards that PingFederate supports have expanded over the years. Organizations implementing workforce and customer solutions are increasingly playing multiple authentication and federation roles. As a result, we are modernizing the PingFederate administrative console. The new dashboard provides Shortcuts to common configurations and Helpful Links that guide you and your PingFederate administrators to complete tasks faster. You can name your PingFederate environment to easily identify it in the upper right corner of the console. If you have deployed PingFederate in a clustered environment, you will also find your nodes on the dashboard with various information at a glance, organized by their respective regions if applicable. Lastly, the new experience comes with a Search bar, where you can find and reach your menu item with just a few keystrokes. To see a list of menu items, see Navigation tabs and menus.

Single sign-on to the administrative console

In addition to the new administrative experience, you can now enable single sign-on for the console. You can configure PingFederate itself as the OpenID Provider, in which case you can create an authentication policy for console access. Alternatively, because the implementation is based on the OpenID Connect specifications, you may use any other standards-compliant OpenID Connect Provider.

OAuth 2.0 authorization to the administrative API

The PingFederate administrative API now supports the OAuth 2.0 authorization framework. When enabled, client applications can simply include an access token in each request as opposed to providing authentication information. This modernization makes it easier and more secure for developers who are familiar with OAuth 2.0 to develop applications that update PingFederate configuration.

Authentication API

Mobile applications can now orchestrate authentication via REST APIs without HTTP redirections. Equipped with this redirectless capability, applications have complete control over the authentication experience, which can help improve user-engagement.

Customer IAM

Authentication sessions control when PingFederate reinvokes authentication sources for users that have previously authenticated. Starting with version 10.1, PingFederate is capable of creating authentication sessions upon user registration, which streamlines the overall user experience.

Additionally, the PingFederate authentication API now supports self-service user registration. With this new enhancement, you can offer your customers a seamless experience as they complete their registrations and potentially access multiple applications.

OAuth

Session Management API

The Session Revocation API allows applications to revoke authentication sessions and to check their revocation status. It does not disclose whether a session is valid or any further information. While this use case remains valid, we are introducing a new API that offers more in version 10.1.

The new Session Management API allows applications to leverage the session identifier to query, extend, or revoke authentication sessions of the users. For example, an application can gain knowledge of whether a session is valid and the relevant information, such as idle timeout and session lifetime, if the session is valid. This new capability allows applications to deliver the desired contents and experiences at different times based on the status of sessions. Like the access to the Session Revocation API, the access to the new Session Management API is configurable on a per client basis.

Session identifier in access tokens

Access tokens can now include the session identifier regardless of whether the Access Token Managers are configured to conjoin the validity of access tokens and the authentication sessions of the users. This new capability enables applications to utilize the new Session Management API as well as the preexisting Session Revocation API, as they both require the session identifier. PingFederate administrators can configure this option on a per-Access Token Manager basis.

Centralized signing keys

PingFederate can now use centralized static or dynamically rotating keys to sign self-contained (JWT) access tokens. If enabled, clients can retrieve the signing keys at the standard /pf/JWKS endpoint for the purpose of validating the integrity of the access tokens issued by PingFederate.

Dynamic client registration management protocol

To support organizations and industries that continue to adopt the Dynamic Client Registration Protocol, we are introducing support for the Dynamic Client Registration Management Protocol (RFC7592), which defines an open standard for developers to manage their registered clients. When enabled, developers can retrieve and update client information on their own; they can also remove client records if you allow them to do so.

Third-party cryptographic software support

PingFederate 10.1 supports Bouncy Castle FIPS as the provider of its Java keystore and cryptographic operations. In Bouncy Castle FIPS mode, whenever PingFederate uses FIPS-approved algorithms, it uses the Bouncy Castle implementation of those algorithms. There are still a number of cases where PingFederate uses algorithms that are not FIPS-approved. For details on the contexts where PingFederate uses algorithms that are not FIPS-approved, contact customer support.

Enhancements for clustered environments

Improved configuration replication time

When consuming configuration data from the console, engine nodes previously paused requests in a queue and resumed processing of requests once the configuration data was applied. While this wait time was typically very brief, it could be longer in some complex environments, which could have a negative impact on the end-user experience. PingFederate 10.1 reduces this wait time dramatically, eliminating end user impact during configuration replication.

Per-SSO transaction state replication

PingFederate 10.1 offers an optional capability to replicate transaction states of a single request from the region that processes the request to other regions in a clustered environment. It solves the rare but possible problem where the initial authentication request arrives at one data center (defined as an adaptive clustering node group) but subsequent requests are fulfilled at another.

Correlation identifier between PingFederate and PingDirectory

Starting with version 10.1, PingFederate sends the tracking IDs of runtime requests, which is always recorded in the PingFederate audit log, to PingDirectory in LDAP requests. As PingDirectory processes these requests, it records the tracking IDs as sessionID values in its access log. There is also a related capability where request parameters received at certain PingFederate endpoints can be sent to PingDirectory to be recorded as requestID values in its access log.

Because the correlation identifiers are recorded on both sides, reviewing log messages from both products can be useful for auditing and troubleshooting purposes.

Administrative API enhancements

The administrative API has been extended to include the following workflows:

• /incomingProxySettings to manage incoming proxy settings.
• /protocolMetadata to manage meta signing and lifetime settings.
• /serviceAuthentication to manage service authentication settings and credentials.

Other improvements

• PingFederate 10.1 introduces a new administrative role: Expression Admin. This role enables users with the administrative role of Admin to add new or update existing attribute mapping expressions, expression-driven issuance criteria, and message customization. Without the Expression Admin role, any Admin-only users are not allowed to introduce new expressions or to replace the current expression with another one.
• The /idp/startSLO.ping application endpoint now supports a new query parameter, LogoutType, to provide a customizable single logout (SLO) experience. This query parameter supports three values: AsyncOnly, SyncOnly, and All.
  • AsyncOnly will cause PingFederate to only log out OpenID Connect and WS-Federation partners in parallel.
  • SyncOnly will cause PingFederate to only log out SAML partners and adapters in series.
  • All will cause PingFederate to log out SAML partners and adapters in series first, followed by OpenID Connect and WS-Federation partners in parallel. Not providing the LogoutType query parameter also has the same effect because this is the default SLO behavior.
• Updated the following bundled components and third-party dependencies:
  • OpenToken Adapter 2.6.2
  • UnboundID LDAP SDK 4.0.13
  • Jackson databind 2.9.10.4
  • Spring Framework 4.3.24
  • JQuery 3.4.1

Resolved issues