Page created: 13 Mar 2020 |
Page updated: 16 Mar 2021
Summary of the latest enhancements, resolved issues, and other improvements for PingFederate.
- 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.
- 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
- /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,
- 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
- OpenToken Adapter 2.6.2
- UnboundID LDAP SDK 4.0.13
- Jackson databind 126.96.36.199
- Spring Framework 4.3.24
- JQuery 3.4.1
|Resolved an issue that could stop PingFederate from responding while it initializes a newly configured plugin.
|Fixed a problem in the administrative console that caused an error when clicking the Manage Certificates button on the Allowed Issuer Certificates window under WS-Trust Mutual SSL Authentication.
|Changes to the <pf_install>/pingfederate/server/default/data/config-store/com.pingidentity.crypto.jwk.MasterKeySet.xml file are now preserved during an upgrade.
|HTTP tracked parameters now work correctly with WS-Federation SP connections.
|The HTML Form Adapter login template now disables the Sign On button while signing on to prevent errors caused by repeated attempts.
|The JIT provisioning configuration no longer gets lost when saving IdP connection changes.
|The HTML Form Adapter validation now ensures that password change and reset options can only be enabled if at least one underlying Password Credential Validator instance configuration supports them.
|All cookies set by the PingFederate administrative console now have the
|When an invalid assertion during client assertion authentication occurs, the HTTP status code 400 is now correctly returned.
|A problem causing the Fail if Policy Engine Finds No Authentication Source option not to display when you do not have the Service Provider role enabled has been resolved.
|When using PingOne for Enterprise with PingFederate Bridge, reconfiguring the PingOne connection is no longer necessary to enable provisioning at a later time if you did not enable it during setup.
|An error in the <pf_install>/ pingfederate/server/default/conf/template/mail-notifications/message-template-username-recovery.html template has been corrected. The greetUser and successMessage variables are now formatted correctly.
|When configuring an SMTP server in the Notification Publisher, any hostname containing valid characters is now accepted, including ones using a non-public suffix.
|Fixed a problem causing the OAuth client to fail if an OAuth client Extended property length was greater than 2048 bytes.
|Fixed a problem preventing some OAuth grant datastores from updating after an archive import.
|PingFederate no longer issues a warning in the server.log when validating access tokens that are issued through the Client Credentials flow through the introspection endpoint.
|Fixed a problem during JSON-token management configuration that allowed the addition of a certificate even when the user-defined Key ID had been used previously.
|Improved the error message returned when an invalid attribute is used while creating or editing an SP connection through the administrative API.
|Messages have been added to the server log when the IRSM state map is purged because it filled up too quickly.
|The outbound provisioning channel timeout now behaves more consistently.