PingOne and PingFederate issue the tokens and assertions that every connected application trusts, so whoever controls their administration, signing keys or OAuth clients controls access to everything behind them. Many Ping estates combine both: PingOne as a cloud service with its own administrator roles and worker applications, and PingFederate as a self-managed federation and OAuth server with local admin accounts, an administrative API, cluster traffic and signing certificates. This guide sets out how access works in each, which settings matter most, what to log and how to roll changes out safely. It is for identity engineers and security architects running Ping in production, and it describes product features as Ping documents them for PingOne and PingFederate 13.1.
Key takeaways
- Treat PingFederate signing keys and the Crypto Admin role as tier zero, because a stolen token-signing key lets an attacker mint SAML or OIDC assertions for any user without a password or MFA.
- Separate the four PingFederate admin roles (User Admin, Admin, Expression Admin, Crypto Admin) and the Auditor role, and move console and API authentication off native local accounts to OIDC, certificates or OAuth.
- PingOne worker applications are administrators without a person behind them: scope their roles to the smallest environment or population and own their client credentials like any privileged secret.
- Harden every OAuth client, not just the server: strong client authentication, exact redirect URIs, restricted scopes, bounded persistent grants and secret rotation with old secrets revoked.
- Ship the logs off the box and off the platform: PingOne keeps user events for 90 days, and PingFederate's admin.log and admin-api.log only help if a SIEM collects and alerts on them.
How identity and access work in PingOne and PingFederate
PingOne is a multi-tenant cloud service. An organisation contains environments; environments contain populations of users, applications, sign-on policies and integrations. Administrators sign in to the admin console through the Administrators environment, and every administrator, human or application, receives access through role assignments scoped to the organisation, an environment, a population or an application. Application types are SAML, OIDC web, native, single page, device authorisation and worker. A worker application is a userless service application that can hold the same roles as human administrators and uses the client_credentials grant by default.
PingFederate is software you run. A clustered deployment has one console node (administration and configuration replication) and engine nodes (runtime SSO and OAuth traffic). Administrators manage it through the administrative console and the administrative API. Runtime trust is defined by IdP and SP connections, adapters, authentication policies, OAuth clients and access token managers, all signed or encrypted with keys managed in the product.
| Area | PingOne | PingFederate |
|---|---|---|
| Who operates the platform | Ping (SaaS); you own configuration | You: hosts, operating system, Java, network, patching and configuration |
| Admin access | Admin console via the Administrators environment, or an external IdP | Admin console and admin API on the console node, local or external authentication |
| Admin roles | Built-in and custom roles scoped to organisation, environment, population or application | User Admin, Admin, Expression Admin, Crypto Admin, Data Collection Admin, Auditor |
| Non-human administrators | Worker applications with role assignments | Admin API clients using OAuth 2.0, JWT or mutual TLS |
| Key material | Managed in the service | Signing and encryption keys, pf.jwk, optional master key encryptor, cluster password |
| Audit data | Audit events in the service, exported by webhooks | Local files: admin.log, admin-event-detail.log, admin-api.log |
For the protocol side of SSO, see the Identity Provider and SSO Security Guide and the SAML Security Guide.
Admin roles and privileged access
PingOne roles
PingOne's built-in roles include Organization Admin, Environment Admin, Identity Data Admin, Identity Data Read-Only Admin, Configuration Read-Only Admin, Client Application Developer, Help Desk Admin, Application Owner, Custom Role Admin, PingOne Privilege Admin, Promotion Admin and the DaVinci Admin roles. Two rules shape least privilege:
- No escalation by assignment: an actor cannot create users or applications with more privileges than it holds; the assigner must hold the same or broader role assignments.
- Creators inherit power: whoever creates an environment receives Environment Admin, Identity Data Admin and Client Application Developer for it, and whoever creates a population receives Identity Data Admin for it. Restrict who can create environments, and review those automatic assignments.
| Role | Can assign | Hardening note |
|---|---|---|
| Organization Admin | Environment Admin | Very few people; no daily use |
| Environment Admin | All roles except Organization Admin | Scope to one environment; separate production from test |
| Identity Data Admin | Identity Data Admin, read-only, Help Desk Admin | Scope to a population where possible |
| Client Application Developer | None | Can create applications, so keep it out of production environments |
| Help Desk Admin | None | Pair with strong caller verification for resets |
| Read-only roles | None | Use for auditors and SOC analysts |
Administrator authentication: under Settings > Administrator Security, admins can authenticate with PingOne, an external IdP, or an external IdP followed by a PingOne MFA request. MFA has been mandatory for all PingOne administrators since 1 June 2025 and cannot be switched off; where an external IdP is the primary source, MFA is enforced there instead. Allowed PingOne methods are an authenticator app (TOTP), FIDO2 and email; prefer FIDO2, since email is the weakest method and the Administrators environment is limited to 100 email notifications per day. The admin sign-on policy is fixed: re-authentication after 30 minutes of inactivity and MFA when the last sign-on was more than 12 hours ago. With "PingOne & External IdP", admins can still sign in directly to PingOne if the IdP connection fails, which gives a built-in recovery path; keep at least one Organization Admin with PingOne credentials and FIDO2 for that purpose and alert on its use. See the Break-Glass Account Guide.
PingFederate roles
| Role | What it allows | Who should hold it |
|---|---|---|
| Admin | Partner connections and most system settings, but not local accounts or local keys and certificates | Federation engineers |
| User Admin | Create and deactivate admin users, reset passwords, install licence keys | A small identity operations group |
| Expression Admin | OGNL expressions in attribute mapping; requires Admin; only Admin plus Expression Admin can be granted User Admin or write access to the install directory | Very few senior engineers, because expressions run code in the server |
| Crypto Admin | Local keys and certificates | Key custodians only, separate from day-to-day Admin |
| Data Collection Admin | Collect support data; requires Admin, User Admin and Crypto Admin | Assigned temporarily for support cases |
| Auditor | View-only across all functions; cannot be combined with other roles | Security reviewers and auditors |
The /bulk, /configArchive and /configStore API endpoints, the Configuration Archive window and Connection Management require all four administrative roles, so any account holding all four is effectively full control and should be rare.
Admin authentication: the console supports native, LDAP, RADIUS, certificate and OIDC authentication; the admin API supports native, LDAP, RADIUS, mutual TLS, OAuth 2.0 and JWT, set independently of the console. Native authentication is the default for new installations. Native accounts lock for one minute after three failed attempts from the same location. Moving the console to OIDC SSO through your workforce IdP puts PingFederate administration behind phishing-resistant MFA and central joiner, mover and leaver processes; with alternative authentication, roles are mapped in configuration files rather than on the Administrative Accounts screen. The pf.console.login.mode property in run.properties can limit the console to one administrator at a time. Keep one native account, with a long random password held in a vault, as an emergency path if the external IdP is unavailable.
Integrations, API tokens and service accounts
PingOne worker applications
- Role scope is the whole risk: with
client_credentials, the worker app's own role assignments decide what its token can do. Assign the narrowest role at the environment or population that the integration needs, never Organization Admin. - User-based grants change the model: if a worker app uses
authorization_codeorimplicit, its tokens carry the signed-in user's roles instead, which suits admin tooling used by people. - Owner and inventory: record an owner, purpose and secret location for every worker app, and remove ones with no recent token issuance. See the Service Account Security Guide.
PingFederate OAuth clients
| Setting | Hardened value | Why |
|---|---|---|
| Client authentication | Private Key JWT or Client TLS Certificate for confidential clients; Client Secret only where unavoidable | Asymmetric credentials are not shared and are harder to replay; None cannot be used with client credentials |
| JWT replay prevention | Enabled, signing algorithm restricted | Each signed client assertion can be used once |
| Client secret storage and rotation | Secret manager; short Client Secret Retention Period; Revoke Previous Secret(s) after cut-over | Old secrets otherwise stay valid |
| Redirect URIs | Exact URIs, no wildcards | Wildcards widen authorisation code interception risk |
| Grant and response types | Only the grants the client uses; Restrict Response Types | Removes unused attack paths |
| Scopes | Restrict Common Scopes; exclusive scopes only where needed; require offline_access for refresh tokens | Limits token reach |
| Request integrity | Require Signed Requests, Pushed Authorization Requests and, for high-value APIs, DPoP | Protects authorisation parameters and binds tokens to a key |
| Access token manager | Restrict to Selected ATM | Stops a client obtaining tokens for other resources |
| Persistent grants | Finite Max Lifetime and Idle Timeout | "Never expire" grants outlive staff and projects |
| Refresh tokens | Roll on use with a short grace period | Stolen refresh tokens become detectable and short-lived |
Stolen client credentials and tokens (ATT&CK T1528 Steal Application Access Token, T1550.001 Application Access Token) are the most common way integrations are abused. See the OAuth 2.0 and OpenID Connect Guide and the Secrets Management Guide.
Admin API clients, keys and the cluster
- Admin API automation: CI/CD pipelines that push PingFederate configuration should authenticate with OAuth 2.0, JWT or mutual TLS, hold only the roles needed, and never use a shared native admin password.
- Signing keys: restrict Crypto Admin, protect key storage with the master key encryptor (or an HSM where your deployment supports one), and plan certificate rotation with partners. In the SolarWinds SUNBURST compromise, attackers with admin rights took a SAML token-signing certificate and forged tokens for federated services (T1606.002 SAML Tokens). See the Cryptographic Key Management Guide.
- Cluster traffic: set
pf.cluster.auth.pwd(generated with theclusterkeyorobfuscateutility) andpf.cluster.encrypt=trueidentically on every node.run.propertiesis not replicated, so each node must be set by hand, and enabling encryption on a running cluster needs a maintenance window. - Key files: engine nodes need the console node's
pf.jwk(andcom.pingidentity.crypto.jwk.MasterKeySet.xmlif a master key encryptor is used). Protect these files with operating system permissions and keep them out of images and source control.
Logging and detection
PingOne retains user events (authentications, user changes) for 90 days, configuration events for two years and DaVinci data for 30 days. For longer retention and correlation, create webhook subscriptions under Monitoring that push audit events in Splunk, New Relic or Ping activity (generic JSON) format, and configure the alerts under Monitoring > Alerts.
PingFederate writes administrator activity to <pf_install>/pingfederate/log/admin.log: sign-on attempts, logouts and timeouts, account and role changes, certificate and OAuth settings changes, connections, adapters, mappings and configuration archive import or export. Setting pf.log.eventdetail=true in run.properties adds admin-event-detail.log with the actual changes, though not for OAuth clients held in LDAP or JDBC stores. Admin API calls go to admin-api.log with user, authentication method, client IP, HTTP method, endpoint and status. Event selection is fixed; detail is adjusted in log4j2.xml. Forward all three files to your SIEM.
| Event | Source | Why alert |
|---|---|---|
| Failed and successful admin sign-ons from new IPs | PingOne audit; admin.log LOGIN_ATTEMPT | Admin credential attacks (T1110.003, T1078.004) |
| Role assignment added, especially Organization or Environment Admin | PingOne configuration events | Privilege escalation |
| New worker application or new client secret | PingOne configuration events | Persistence through non-human admins (T1098.001) |
| Certificate, key or signing settings changed | admin.log | Possible preparation for token forgery |
| New IdP connection, adapter or authentication policy change | admin.log | A new trusted assertion source can bypass MFA |
Configuration archive export or /bulk call | admin.log, admin-api.log | Full configuration, including connections, leaves the server |
| Administrator Security settings changed | PingOne configuration events | Admin authentication weakened |
Metrics
- Number of accounts holding all four PingFederate admin roles, and of PingOne Organization Admins (target: minimal and named).
- Percentage of administrators using FIDO2 or phishing-resistant external IdP MFA.
- Percentage of confidential OAuth clients using Private Key JWT or mutual TLS rather than client secrets.
- Number of OAuth clients with wildcard redirect URIs or never-expiring persistent grants (target: zero).
- Median age of worker app and client secrets.
- Days of PingOne and PingFederate audit data available in the SIEM.
See the ITDR Guide and the SIEM Guide.
Hardening baseline
Decisions to make first
- PingOne admin authentication, PingOne or external IdP: an external IdP centralises lifecycle and lets you require phishing-resistant MFA; "PingOne & External IdP" adds a second factor and a fallback, at the cost of a direct PingOne sign-in path you must monitor. Small teams with one IdP often keep PingOne authentication with FIDO2.
- PingFederate console, native or OIDC: native is simplest for small single-team deployments; OIDC suits larger teams that need MFA and leaver processing. Keep one vaulted native account for recovery either way.
- Client authentication: mutual TLS needs a secondary HTTPS port and certificate management; Private Key JWT needs only a published JWKS; client secrets are acceptable only for low-risk clients with rotation.
Rolling it out
- Snapshot first: export a PingFederate configuration archive and record PingOne role assignments and Administrator Security settings, so every change has a rollback point.
- Turn on logging: webhooks from PingOne, file forwarding and
pf.log.eventdetailon PingFederate, and the alerts in the table above. - Fix administration: separate PingFederate roles, move console and API to external authentication in a test environment, test the emergency native account, then promote. Reduce PingOne Organization and Environment Admins and switch admins to FIDO2.
- Secure the platform layer: enable cluster authentication and encryption in a maintenance window, lock down key files, restrict network access to the console and admin API to administration networks.
- Harden OAuth clients in waves: start with clients for high-value APIs, change one setting at a time (redirect URIs, scopes, client authentication), test in a non-production environment, and use the client secret retention period to overlap old and new secrets before revoking.
- Review quarterly: role assignments, worker apps, OAuth clients, signing certificate expiry and the metrics above.
Framework mapping
| Ping control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK techniques addressed |
|---|---|---|---|
| Admin MFA, external admin authentication | IA-2(1), AC-2(7) | PR.AA-03 | T1110.003, T1078.004 |
| Role separation and scoping | AC-6, AC-6(5) | PR.AA-05 | T1098.003 |
| Worker apps and OAuth client credentials | IA-9, IA-5 | PR.AA-01 | T1098.001, T1528, T1550.001 |
| Signing keys and cluster encryption | SC-12, SC-8 | PR.DS-02 | T1606.002 |
| Configuration baseline and change control | CM-6 | PR.PS-01 | T1484.002 (new trust sources) |
| Audit logging and SIEM forwarding | AU-2, AU-6, AU-12 | PR.PS-04, DE.CM-03 | Detection of all of the above |
Common misconfigurations
- One "super admin" account for PingFederate: a shared native account with all four roles, used by several engineers and by automation, makes changes unattributable and gives any leak full control including keys.
- Over-scoped worker apps: a worker app created for user provisioning holding Environment Admin across production, with a client secret in a script or pipeline variable.
- Wildcard redirect URIs and never-expiring grants: convenient during development, then promoted to production unchanged.
- Old client secrets left valid: secrets rotated but previous ones never revoked, so a leaked old secret still works.
- Unencrypted cluster traffic and exposed admin ports:
pf.cluster.encryptleft false and the admin console reachable from user networks. - Logs left on the server: admin.log rotating locally with nobody watching, so key or connection changes go unnoticed, which is exactly the window a token forger needs.
Practitioner checklist
- Require FIDO2 or phishing-resistant external IdP MFA for every PingOne administrator and keep one monitored recovery admin.
- Reduce PingOne Organization and Environment Admins; scope other roles to environments and populations.
- Split PingFederate Admin, User Admin, Expression Admin and Crypto Admin across different people; use Auditor for reviewers.
- Move the PingFederate console and admin API to OIDC, certificate, OAuth or JWT authentication, with one vaulted native recovery account.
- Inventory worker apps and OAuth clients with owners; remove unused ones and narrow their roles and scopes.
- Use Private Key JWT or mutual TLS for confidential clients, exact redirect URIs, restricted scopes and finite grant lifetimes.
- Rotate client secrets with a short retention period and revoke previous secrets after cut-over.
- Enable
pf.cluster.encryptand cluster authentication on all nodes and protectpf.jwkand master key files. - Forward admin.log, admin-event-detail.log, admin-api.log and PingOne webhooks to the SIEM, with alerts on key, connection and role changes.
- Export a configuration archive before every significant change and review the baseline quarterly.
Standards and references
- Ping Identity: PingFederate administrative accounts
- Ping Identity: PingFederate configuring OAuth clients
- Ping Identity: PingFederate administrator audit logging
- Ping Identity: PingFederate cluster encryption and authentication
- Ping Identity: PingOne predefined roles
- Ping Identity: PingOne administrator security
- Ping Identity: PingOne logging and reporting
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · Okta Security Hardening Guide · Entra ID Security Guide · OAuth Token Exchange and Delegation Guide · Web Application Attacks Guide