The web browser single sign-on (SSO) feature allows your users to access AppNeta Performance Manager (APM) using their existing corporate credentials. They do not require separate APM credentials. Advantages include:

  • No new credentials for users to remember
  • No login required when accessing a deep link
  • Centralized management of credentials (eg: password policy, lockouts, audit, etc.)
  • No storage of, or access to, credentials by APM
  • Auto-provisioning of users into APM
  • Automated role assignments based on group membership

APM supports SAML-based SSO. In this model, APM communicates with a Service Provider (SP) which, in turn, communicates with an Identity Provider (IdP) that you control. In all deployments, the SAML SP function is provided by Ping. The critical IdP function, whether it is on-premise or cloud-based, must be SAML2.0-compliant (for example, AD FS, Okta, Ping, AzureIdP, Google IdP, etc.) and is your choice.

Several deployment types are available, depending on your security needs. For example:

  • APM-Public with PingOne Identity Bridge - Public version of APM with an external SAML Identity Bridge. For example, the following diagram shows SAML SSO with APM-Public, a PingOne SAML Identity Bridge (SP), and on-premise IdP.
    SSO image 1
  • APM-Private with PingOne Identity Bridge - Private version of APM with an external SAML Identity Bridge. For example, the following diagram shows SAML SSO with APM-Private, a PingOne SAML Identity Bridge (SP), and on-premise IdP.
    SSO image 2
  • APM-Private with PingFederate Server - Private version of APM with internal SAML federation server as SP. For example, the following diagram shows SAML SSO with APM-Private, a PingOne PingFederate Server (SP), and on-premise IdP.
    SSO image 3

The deployment chosen depends on your corporate security policy. APM-Public is used for ease of deployment. APM-Private is used in order to keep all measurement data within your corporate network. APM-Private with a PingFederate SP is used to allow the entire application and identity framework to operate within your corporate network.

Security model

No matter which deployment you use, Ping’s proven SAML implementation ensures a completely secure authentication and single sign-on experience.

  • The entire authentication transaction is accomplished using browser redirects and SAML exchanges.
  • User credentials are never exposed beyond your corporate IdP. APM never has access to them.
  • The only information exchanged between the IdP and PingOne is an encrypted SAML token which contains:
    • email. Normally an email address.
    • groups. Normally group memberships of the user. Used for authorization.
    • Optionally first and last name for auto-user creation.


After successful SAML authentication, users can be automatically assigned APM roles (ie. authorized) based on their group memberships. To do this, APM makes a REST API call to PingOne over SSL using the access token to query for the group membership. Based on this and the group->role mapping, a role is auto-assigned.

Group attribute

Although most customers use the member: attribute for auto role assignment, this does contain all the user’s group memberships. If this is of concern, it’s possible to use claim rules on your IdP to send only the groups required for a user to be given the appropriate APM role.

Organization access

For customers with multiple child organizations, users’ access to child organizations can be controlled through the use of a custom attribute: OrgNames. This single-valued attribute contains a comma-separated list of child organizations to which the user may be granted access once successfully authenticated. If the OrgNames attribute is not set, the user may access any child organization on authentication.

Protocols and ports used

The following protocols and ports are used for SAML requests:

  • Pingone SAML requests - TCP Port 443 (default - can be customized)
  • PingFederate SAML requests - TCP Port 9031

Set up SSO

Note: Coordination with AppNeta Support is required to set up SSO.

Step 1: Send IdP SAML metadata to AppNeta

  1. Within your IdP, generate an IdP SAML metadata (entity descriptor) file.
  2. Contact AppNeta Support and ask them to add the IdP to your organization in APM. Provide them the following:
    • The IdP SAML metadata (entity descriptor) file you generated.
    • The APM organizations you control that you want to use single sign-on.
    • If your deployment model is APM-Public with PingOne Identity Bridge:
      • A keyword to use for your new custom URL. It will take the form https://<keyword>
    • If your deployment model is APM-Private with PingOne Identity Bridge:
      • A keyword to use for your new custom URL. To determine the keyword:
        1. Navigate to > Manage Identity Provider.
        2. In the Login URL column, find the keyword in the form https://<FQDN>:443/pvc/?sitename= <keyword>
    • If your deployment model is APM-Private with PingFederate Server:
      • Nothing else is required.
  3. AppNeta Support will provide you with an APM SAML metadata (entity descriptor) file.

Step 2: Install APM SAML metadata on your IdP

  1. Within your IdP, register APM as a service provider using the APM SAML metadata (entity descriptor) file provided by AppNeta Support.

Step 3: Map IdP SAML attributes

  1. Within your IdP, map the correct attributes from the corporate directory to properties in SAML assertions that APM expects. For example, for an Active Directory IdP this looks as follows:

    Active Directory attribute SAML property
    mail NameID *
    (also set nameid-format to emailAddress)
    mail email *
    givenName firstName
    sn lastName *
    member groups *
    title title
    (or mobile)
    extensionAttribute1#OrgNames orgNames

    (* = required)

Step 4: Configure SSO access control on APM

  1. Within APM, login as a user with Organization Admin credentials.
  2. Navigate to > Manage Identity Provider.
  3. For the identity provider you want to edit, select > Edit.
  4. In the Organization field, select the organizations you want SSO users at the selected identity provider to have access to.
  5. In the Role Mapping field, map security groups in your IdP to user roles within APM.
    • All users that you want to log in via SSO must belong to a group that is mapped to an APM role.
    • All mapped groups will have access to all organizations specified.
  6. If you are using APM-Private and an external SP, port 443 on your firewall must be open between the APM-Private server and the PingOne SP.
  7. Notify AppNeta Support that the configuration is complete.
    • AppNeta Support will enable single sign-on.
    • Users can then access APM via https://<keyword> (where “<keyword>” is the keyword you provided).

SSO behavior

Upon enabling SSO:

  • Users in a mapped security group may log in to APM in via your custom URL (https://<keyword> ).
  • Once users log in to the custom URL for the first time, access via the regular APM login will be automatically disabled.

Upon disabling SSO:

  • Single sign-on is disabled for the organizations associated with the identity provider.
  • Users in mapped security groups will have their federated profiles converted to local profiles, which must then be managed via the Manage Users page.
  • Affected users must revert to logging in via the regular APM login.
  • Affected users must reset their passwords before they can log in again.
  • Notifications will continue to be delivered to affected users.