PingAccess

Creating web sessions

Create a new web session in PingAccess to define a policy for web application session creation, lifetime, timeouts, and scope. You can apply the same web session to multiple target applications.

Before you begin

If you are using PingFederate as the OpenID Connect (OIDC) token provider and plan to use Mutual TLS, you must make two changes to the PingFederate configuration:

  1. Enable the use of the secondary HTTPS port in PingFederate by editing the <PF_HOME>/pingfederate/bin/run.properties file and setting the pf.secondary.https.port property to a port value. Learn more in Configuring PingFederate properties.

  2. Edit the openid-configuration.template.json file to add the mtls_endpoint_aliases object, with content defined by RFC-8705. Learn more about this file in customizing the OpenID provider configuration endpoint response.

Steps

  1. Click Access, then go to Web Sessions > Web Sessions.

  2. Click Add Web Session.

  3. In the Name field, enter a unique name for the web session.

    The name can be up to 64 characters, including special characters and spaces.

  4. In the Cookie Type list, select a type of token to create.

    Choose from:

    • Encrypted JWT (default): An encrypted JSON Web Token (JWT) uses authenticated encryption to simultaneously provide confidentiality, integrity, and authenticity of the PingAccess token.

    • Signed JWT: A signed JWT uses asymmetric cryptography with a private-public key pairing to verify the signed message and confirm that it wasn’t modified during transit.

      Changing this setting could affect existing ongoing sessions, forcing the user to reauthenticate to access protected resources.

  5. In the Audience field, enter a short, unique identifier between 1 - 32 characters to define the audience to which the PingAccess token applies.

    Requests made to a target application that’s associated with this web session must have a PingAccess token that matches the configured audience value. Otherwise, PingAccess redirects to the OIDC provider.

    Changing this setting can affect existing ongoing sessions, forcing the user to reauthenticate to access protected resources.

  6. In the OpenID Connect Login Type list, select a method of verifying the user and collecting additional profile claims.

    OIDC supports three login types that define how the user’s identity is verified based on authentication performed by an OpenID Provider, and how additional profile claims are obtained. Three OIDC sign-on profiles are supported: Code, POST, and x_post.

    Choose from:

    • Code: A standard OIDC login flow that provides confidentiality for sensitive user claims. In this profile the relying party, PingAccess, makes multiple back-channel requests to exchange an authorization code for an ID token. PingAccess then exchanges an access token for additional profile claims from the UserInfo endpoint at the provider, PingFederate. Use this login type for maximum security and standards interoperability.

    • POST: A login flow that uses the form_post response mode. This flow follows the OAuth 2.0 Form Post Response Mode draft specification and requires PingFederate 7.3 or later.

      After authentication, PingFederate sends a form auto-POST response containing the ID token, including profile claims, to PingAccess through the browser. Backchannel communication between PingAccess and PingFederate is required for key management to validate ID tokens. If the exchanged claims do not contain information that should be hidden from the end user, use this login type for maximum performance.

      Select the Implicit grant type when configuring the OAuth Client within PingFederate. Learn more in Configuring OAuth clients. You must set the ID token-signing algorithm in PingFederate to one of the ECDSA or RSA algorithms.

    • x_post: A login flow based on OIDC that passes claims from the provider through the browser. Select the Implicit grant type and use one of the ECDSA or RSA algorithms as the ID token-signing algorithm.

      If you are using PingFederate 7.3 or later, use POST rather than x_post, which Ping Identity defined prior to the development of the OAuth 2.0 Form Post Response Mode draft specification.

  7. In the Client ID field, select the unique identifier that you were assigned when creating the OAuth relying party client within the OpenID provider.

    If PingFederate is the OpenID provider, learn more in Configuring OAuth clients.

  8. In the Client Credentials Type section, click the type of credential that you were assigned when you created the OAuth relying party client within the OpenID provider, then provide the corresponding information.

    If you enable session validation or configure the Code login type, this field is required.

    Choose from:

    • Secret: Enter the Client Secret that was assigned when you created the OAuth relying party client within the token provider.

    • Mutual TLS: Select a configured Key Pair to use for Mutual TLS client authentication.

    • Private Key JWT: If you selected the Enable Static Keys check box on the Static OAuth & OpenID Connect Keys page, you must select an active Signing Algorithm.

      If you have not selected Enable Static Keys, the Signing Algorithm field is optional and defaults to the dynamic signing algorithm set on the OAuth Key Management page. Learn more in Configuring static signing keys.

    If PingFederate is the OpenID provider, the OAuth client that you use with PingAccess web sessions must have an OIDC policy specified. Learn more in Configuring OpenID Connect Policies.

  9. In the Idle Timeout field, enter the amount of time, in minutes, that the PingAccess token remains active if PingAccess doesn’t detect any user activity.

    The default value is 60 minutes. If an idle timeout occurs, PingAccess automatically terminates the associated session.

    If the user has a valid existing PingFederate session when an idle timeout occurs in an associated PingAccess session, the PingAccess session might re-establish itself without prompting the user to sign on again.

  10. In the Max Timeout field, enter a maximum amount of time, in minutes, that the PingAccess token remains active.

    The default value is 240 minutes. When the PingAccess token expires, the associated user must reauthenticate. This protects against unauthorized resource use by ensuring that sessions end by the specified time and require the associated user to reauthenticate to continue.

    If PingFederate is the token provider, this value must be smaller than the PingFederate access token lifetime defined in the PingFederate access token management instance. Learn more in Reference token management.

  11. Optional: To configure advanced settings, click Show Advanced.

    Learn more about the configuration options in Configuring advanced web session settings.

  12. Click Save.