Guides

Ping Identity

Overview

ID Dataweb integrates with PingFederate to add identity verification and risk assessment to any authentication flow. When a user authenticates, PingFederate invokes the ID Dataweb IdP Adapter, which runs the configured verification services and returns a policy decision. PingFederate authentication policies branch based on that decision — approving trusted users, routing medium-risk sessions to step-up verification, or blocking high-risk sessions outright.

The integration supports any ID Dataweb workflow: phone-based identity matching, document verification, MFA, and passive device/session risk — all configurable per tenant without code changes.

flowchart LR
    User([User attempts access]) --> App[Protected Application]
    App --> PF[PingFederate\nAuth Policy]
    PF --> DP[Device Profiling\nThreatMetrix]
    DP --> IDW[ID Dataweb\nVerification]
    IDW --> D{policyDecision}
    D -->|approve| Allow([Authentication\ncontinues])
    D -->|obligation| StepUp([Step-up\nverification])
    D -->|deny| Block([Authentication\nblocked])

Prerequisites

PingFederate side:

PingFederate 11.3 or later, installed and running.

Administrative access to the PingFederate console.

ID DataWeb Integration Kit installed in PingFederate.

Ability to configure IdP adapters, authentication policies, and attribute mappings.

ID Dataweb side:

Active ID Dataweb tenant with verification services configured.

API credentials issued by ID Dataweb for the integration.

Policy configuration in ID Dataweb returning a policyDecision on each request.

Available Workflows

The integration supports any ID Dataweb workflow. PingFederate branches its authentication policy on the policyDecision value returned — approve, obligation, or deny — regardless of which verification path ran.

Recommended workflows for PingFederate deployments:

→ Identity Verification — Phone-based identity match with automatic document step-up. Highest pass rates for onboarding flows.

→ Continuous Re-Authentication — Passive session risk at every login. Trusted devices approved silently; unknown or risky sessions stepped up to SMS Link.

→ NIST IAL2 — Full NIST IAL2-compliant flow for regulated use cases requiring document + biometric verification.

Contact your ID Dataweb team to configure the appropriate workflow for your deployment.

Configuration Steps

sequenceDiagram
    participant User as End User
    participant App as Application
    participant PF as PingFederate
    participant IDW as ID Dataweb

    User->>App: Access attempt
    App->>PF: Authentication request
    Note over PF: Device profiling tag runs silently (ThreatMetrix)
    PF->>IDW: Verification request via IdP Adapter
    Note over IDW: Evaluates device, risk, and identity signals
    IDW-->>PF: policyDecision + verification attributes
    alt approve
        PF-->>App: Authentication continues
        App-->>User: Access granted
    else obligation
        PF-->>User: Step-up verification required
        User-->>PF: Completes verification
        PF-->>App: Authentication continues
    else deny
        PF-->>User: Authentication blocked
    end

Step 1: Create an ID Dataweb IdP Adapter instance

In PingFederate, navigate to Authentication → Integration → IdP Adapters. Select Create New Instance and choose ID DataWeb IdP Adapter as the adapter type. Provide an instance name and instance ID.

Step 2: Configure adapter settings

Configure connection settings for the adapter: ID Dataweb API connection settings, authentication credentials, device profiling configuration (ThreatMetrix), and any optional adapter settings.

Step 3: Configure attribute mappings

Define the attributes sent from PingFederate to ID Dataweb — for example, email address, user identifier, and any additional user attributes required by your verification policy.

Step 4: Configure response attribute mappings

Map values returned from ID Dataweb back into PingFederate attributes using JSON pointer expressions. Key response values to map: policyDecision, trustScore, and any verification assertions your policy rules reference.

Step 5: Add the adapter to the authentication policy

In PingFederate, navigate to Authentication → Policies. Add the ID Dataweb adapter as a step in the authentication flow. Configure attribute contracts so that user identifiers are passed into the adapter.

Step 6: Configure policy decision branching

Create authentication policy rules based on the policyDecision attribute returned from ID Dataweb:

approve → allow authentication to continue.

obligation → route to additional verification or step-up.

deny → block authentication.

Testing

End-to-end verification sequence:

  1. User initiates authentication to an application protected by PingFederate.
  2. PingFederate executes the configured authentication policy.
  3. Device profiling runs and collects device intelligence data.
  4. The ID Dataweb IdP Adapter sends a verification request.
  5. ID Dataweb processes the request and returns a policy decision.
  6. PingFederate evaluates the returned attributes.
  7. Authentication flow continues according to the configured policy rules.

Expected results:

ID Dataweb verification response is received by PingFederate. The policyDecision attribute is populated. The authentication policy branches based on the decision value.

Use ID Dataweb preproduction credentials and test data to validate each decision path (approve, obligation, deny) before going live. See Testing Reference for test credentials per workflow.

Best Practices

Adapter not returning expected attributes

Possible cause: response attribute mappings are incorrectly configured. Verify JSON pointer mappings for all response attributes in the adapter configuration.

Authentication policy does not branch correctly

Possible cause: authentication rules are not referencing the correct attribute. Confirm policy rules evaluate the policyDecision attribute specifically.

Verification data missing from request

Possible cause: required attributes are not mapped into the adapter. Confirm attribute mappings between PingFederate and ID Dataweb cover all attributes your verification policy expects.

Device profiling not collected

Possible cause: device profiling configuration is missing or misconfigured in the adapter settings. Verify ThreatMetrix device profiling is enabled and the profiling tag is loading on the authentication page.

Updated 2 days ago