PingOne SAML Tutorial For Beginners

SAML Applications and Attribute Mapping in PingOne

Security Assertion Markup Language (SAML) is a widely used open standard for enabling Single Sign-On (SSO) in browser-based applications.

It is XML-based and works seamlessly across multiple-page applications and SaaS platforms.

By implementing SAML, organisations can simplify authentication, strengthen security, and improve user experience.

A step-by-step process for configuring a SAML application—including how to map attributes in a Ping console.

Understanding the Basics of SAML in PingOne

At the core of SAML are two key transactions:

SAML Request – Initiated by the Service Provider (SP), this request asks the Identity Provider (IdP) to authenticate a user.

SAML Response – After successful authentication, the IdP generates and returns a signed SAML assertion (response). This assertion contains user details and authentication confirmation.

Key Roles in SAML

Identity Provider (IdP): Responsible for authenticating the user. It issues the SAML response containing the authentication status and attributes.

Service Provider (SP): Provides the actual application or service. It relies on the IdP to verify user identity before granting access.

The IdP signs the SAML assertion or response using certificates, ensuring secure communication between the two providers.

Depending on the configuration, the IdP can sign either the entire response or just the assertion.

Sending User Attributes in PingOne

SAML supports sending user attributes to applications for authorisation purposes. Attributes can include:

First Name

Last Name

Email Address

Mobile Number

Using the Groups configuration, organisations can also authorise users based on group membership. This ensures role-based access control within applications.

Step-by-Step SAML Application in PingOne

When creating a new SAML-based application, the typical flow involves five steps:

1. Add an Application

Click “Add Application”.

Choose SAML as the application type.

Provide a name, test type, and entity ID.

Upload metadata manually or import it via a file/URL.

Save the configuration.

2. Overview

This section provides a summary of the application, including:

Application name

Application type

Metadata details

3. Configure Settings

In this step, you configure critical SAML details, such as:

Certificates

SSL/TLS URLs

Entity IDs

Authentication policies

Here, you define authentication rules. For example:

First-factor authentication (password login)

Multi-factor authentication (MFA)

Domain or IP-based authentication rules

5. Attribute Mapping

Configure the attributes to be passed to the SP, such as first name, last name, email, and mobile number.

This step ensures proper authorisation within the application.

Attribute Mapping in Ping Console

Mapping attributes is an essential part of SAML setup, as it determines which user details are shared with the application. In Ping, attribute mapping involves:

Editing the attribute section

Adding new attributes like email or username

Ensuring the SAML Subject uses a unique value (preferably email or username, instead of user ID)

This approach ensures the application can correctly identify users during login.

Policies and Authentication in PingOne

Ping supports multiple policies for authentication. The default policy is single-factor authentication, but you can configure others, such as:

Multi-factor authentication (MFA)

Domain-specific login policies

Registration flows

Custom agreements

Applications will use the default policy unless a specific policy is explicitly assigned.

1. Authentication Policies: Starting with Single-Factor Login in Ping

The most basic authentication policy is the standard login policy, which uses a single factor. This policy can be expanded and customised with options such as:

Account recovery methods

Session validity limits

Support for additional identity providers in the future

If a user’s account is locked, authentication will be blocked—though this is not always a required configuration.

When creating a single-factor authentication policy in the cloud, note that there is no Identity Federation Hub. Instead, authentication can rely on external identity providers (IDPs). These providers handle the authentication, pass attributes, and generate what’s known as an Amul Response Action.

To create a policy, you might name it something like policy_login and build upon it later with MFA policies.

2. Adding MFA to Authentication Policies in PingOne

MFA policies provide an extra layer of security and are managed separately from the base login policy. The MFA settings panel allows administrators to:

Add optional actions (conditions)

Trigger MFA only for specific groups of users

Apply MFA based on IP address restrictions or exceptions

For example:

If a user belongs to Group A, MFA may be enforced.

If a login attempt originates from an untrusted IP range, MFA is triggered.

This flexibility enables organisations to adopt a contextual approach to authentication.

3. Introducing PingOne Risk and PingOne Protection

A major development in authentication is risk-based authentication, powered by Ping Identity’s solutions.

PingOne Risk analyses login attempts based on factors such as:

IP address reputation

Geolocation

Network certificates

If the system detects suspicious activity, it automatically enforces MFA.

PingOne Protection is a licensed cloud solution designed to enhance security through geolocation awareness and network trust validation.

One of the core features of PingOne Risk is the ability to verify trusted networks through certificates, ensuring users are connecting from secure environments.

Although still relatively new in the market, PingOne Risk is expected to gain wider adoption in the coming years.

Companies like Oracle are already experimenting with advanced technologies such as Direct Ping Identity and Direct Ping for next-generation identity verification.

4. Custom MFA Policies and Group-Based Authentication in PingOne

Organizations often need application-specific MFA policies.

For example: A Salesforce policy may enforce MFA only for certain user groups.

Another policy may require email-only MFA for a different application.

This customisation is possible by editing user attributes and group associations. Administrators can:

Trigger MFA only for selected groups

Add or remove users from MFA policies dynamically

Create separate MFA rules depending on the application context

5. Consent and Agreement Pages in PingOne

Another essential aspect of authentication management is user agreements. Organisations can configure:

Terms & Conditions pages

Consent agreements that must be accepted before continuing authentication

These agreements can be customised (e.g., 90 days, 180 days) and re-prompted based on organisational policies.

6. PingOne External Identity Provider Integration

The integration of external IDs (e.g., Google, Facebook, LinkedIn, Yahoo) enables seamless single sign-on (SSO).

The process typically involves: Creating a project and generating a client ID/secret.

Configuring API access and enabling services (e.g., Google People API).

Adding redirect and callback URLs in the Ping console.

Linking external credentials to existing Ping accounts.

This configuration ensures cross-platform authentication without duplicating accounts.