1. Go to Applications > Applications and browse or search for the application that you want to edit.
  2. Click the application entry to open the details panel.
  3. On the Overview tab, click the Pencil icon and enter or edit the following:
    Field Description

    Application Name

    A unique identifier for the application.

    Description (optional)

    A brief description of the application.

    Icon (optional)

    A pictorial representation of the application.

    Use a file up to 1MB in JPG, JPEG, GIF, or PNG format.

    Home Page URL

    The default home page for the application.

    Signon URL

    The URL to which the application redirects the end user for sign-on.

    Note:

    If you created this application using the Application Catalog page, you can enable advanced configuration options. Click the Enable Advanced Configuration button to access all application settings on the Configuration tab.

  4. On the Configuration tab, click the Pencil icon and enter or edit the following:
    Field Description

    ACS URLs

    The Assertion Consumer Service (ACS) URLs. You must specify at least one URL. The first URL in the list is used as the default.

    If the service provider includes the optional AssertionConsumerServiceURL element in authentication requests, the incoming value must match one of the URLs defined here.

    Signing key

    The certificate that confirms that requests, responses, and assertions actually came from the service provider (SP).

    Select the appropriate certificate from the list of available RSA or EC certificates. To add a certificate, see Adding a certificate and key pair.

    Select whether to sign assertions, responses, or assertions and responses.

    Select the algorithm to use for signing metadata. If you select an RSA signing certificate, the options are RSA_SHA256, RSA_SHA384, and RSA_SHA512. If you select an EC signing certificate, the options are SHA256_ECDSA, SHA384_ECDSA, and SHA512_ECDSA.

    Encryption

    If selected, the assertions PingOne sends to the SAML application are encrypted.

    Note:

    Available for SAML 2.0 applications only.

    Select the algorithm for encrypting the assertions, either AES_128 or AES_256 (recommended).

    Import a certificate or select an existing one from the list of available certificates. To add a certificate, see Adding a certificate and key pair.

    Entity ID

    The service provider entity ID used to look up the application. This is a required property and is unique within the environment.

    SLO endpoint

    The URL of the single logout (SLO) service. PingOne redirects the browser to this location when it needs to send an SLO message to the service provider. For more information, see SAML 2.0 single logout.

    SLO response endpoint (optional)

    The URL of the SLO response service. You can use this option if you have a separate service for SLO responses. If this value is blank, PingOne sends responses to the SLO endpoint.

    SLO window

    Defines how long PingOne can exchange logout messages with the application, specifically a LogoutRequest from the application, after the initial request.

    PingOne can also send a LogoutRequest to the application when SLO is initiated by the user from other session participants, such as an application or identity provider (IdP). This setting is per application. This logout is separate from the user session logout that revokes all tokens. The minimum value is 1 hour and the maximum is 24 hours. You should start with a value of 2 hours and then fine-tune as needed.

    SLO binding

    The SAML binding used by the application. The default is HTTP POST. Select HTTP Redirect as needed.

    Subject NameID format

    A string that specifies the format of the subject NameID attribute in the SAML assertion. Options are:

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (default). The subject NameID is not specified. Use this format if you are not sure which format to use.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. The subject NameID is in the form of an email address.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. The subject NameID is an opaque unique identifier for a user that retains the same value over time.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient. The subject NameID is a randomly generated identifier. A different value is used for each single sign-on (SSO) for a given user.

    Assertion validity duration

    The maximum amount of time that an assertion is valid (in seconds).

    Target application URL

    This option is required by some applications as the target URL. It's used in IdP-initiated SSO for deep linking. The application URL is passed in the RelayState parameter by the IdP.

    Enforce Signed AuthnRequest

    If selected, PingOne accepts only signed SAML requests and rejects unsigned SAML requests. Verifying the digital signature enables PingOne to validate the authenticity and integrity of the SAML request. This can help mitigate data tampering attacks on attributes, such as the RequestedAuthnContext element in AuthnRequest. For more information, see RequestedAuthnContext.

    Verification certificate

    A certificate that confirms that the SAML assertions actually came from the sender. Select or import the appropriate certificate. The list shows the certificates that are available. To add a certificate, see Adding a certificate and key pair.

    Select Policy based on RequestedAuthnContext

    If selected, and if the RequestedAuthnContext value is an exact match to one of the configured policies, PingOne invokes the policy. Otherwise, it returns an error to the application. For more information, see RequestedAuthnContext.

    CORS Settings

    Specifies the cross-origin resource sharing (CORS) options for the application. For more information, see Cross-origin resource sharing.

    • Allow any CORS-safe origin (default): Allows the application to access resources from a domain that is CORS-safelisted, according to the Fetch specification at https://fetch.spec.whatwg.org/#cors-safelisted-request-header.
    • Allow specific origins: Allows the application to access resources from a specific domain.
      • Allowed origins: Specifies the allowed origin domains for CORS. You can specify a domain pattern or a valid IPv4 address. If you use a domain pattern you can specify one wildcard to match incoming requests.
        Note:

        You cannot use the wildcard on the domain name.

        For example, the following search patterns are valid:

        • https://*.test.com
        • https://www.app*.test.com

        The following patterns are not valid:

        • https://test*.com
        • https://www.app.test*.com
    • Disallow all origins: Don’t allow the application to access resources from a cross-origin domain.
    Note:

    After you make changes to the CORS Settings, it can take several minutes for the new settings to take effect, due to time-to-live configuration on the resource.

  5. On the Attribute mappings tab, click the Pencil icon and select a PingOne user attribute and map it to an attribute in the application. For more information, see Mapping attributes.
    1. Enter a SAML attribute and then select the corresponding PingOne attribute from the list.
    2. Click the More Options (⋮) icon to configure nameFormat for the SAML attribute. To use a name format other than Subject, select an option from the list.

      If you don't select an option, PingOne uses the basic format as default. The options are:

      • uri: The attribute follows the convention for URI references. The interpretation of the URI content is application-specific.
      • basic: The strings in the attribute must be drawn from the values belonging to the primitive type xs:Name.
      • unspecified: The attribute can be any format. The interpretation of the content is application specific.
    3. Click the Gear icon to use the expression builder to build an attribute mapping. See Using the expression builder.
    4. Select Required to define the attribute as required for the application.
  6. On the Policies tab, click the Pencil icon and select the authentication policies for the application.

    If you have a DaVinci license, you can select PingOne policies or DaVinci Flow policies, but not both. If you don’t have a DaVinci license, you’ll see PingOne policies only.

    To use a PingOne policy, click + Add policies and then select the policies that you want to apply to the application. Click Add. The policies are applied in the order in which they appear in the list. PingOne evaluates the first policy in the list first. If the requirements of the policy are not met, PingOne moves to the next policy in the list. For more information, see Authentication policies for applications.

    To use a DaVinci Flow policy, you must clear all PingOne policies. Click the Deselect all PingOne policies button. In the confirmation message, click Continue. Click the DaVinci Policies tab, and then select the policies that you want to apply to the application. PingOne applies the first policy in the list.

  7. On the Access tab, click the Pencil icon and enter or edit the following:
    Field Description

    Application portal display

    Determines whether an application icon appears in the application portal even if the user is allowed to access the application in the application portal based on the group membership policy. For more information, see Application access control.

    Admin only access

    Specifies that a user with an administrator role is required to access the application. The user must have one of the following roles:

    • Organization Admin
    • Environment Admin
    • Identity Data Admin
    • Client Application Developer

    Group membership policy

    Select the group membership policy for the application. For more information, see Groups.

  8. Click Save.