TL;DR
If you’ve done AWS security work, you already have the mental model for a Ping Identity deployment. You just have it filed under different nouns, and split across one console instead of five products. IAM users, groups, and policies; IAM identity providers and role trust; CloudTrail. Ping does the same jobs, but structurally splits them across PingDirectory, PingFederate, PingAccess, PingAuthorize, and PingOne, each owning one layer of the request path instead of one engine owning all of them. This post maps the layers, works one deployment through all five, and names the place where the mapping actually gets hard: the word “role” means two unrelated things depending which side of the map you’re standing on.
The reframe: you’re not learning a new discipline, you’re learning new nouns
“You’ve Been Doing Federation Since Day One” made the case that AssumeRoleWithWebIdentity and a cross-vendor SAML trust are the same primitive with different vendor labels. That post stayed inside one layer: trust. This one is broader. It’s the map for everything else an AWS security practitioner runs into on day one in a Ping-based environment: where the identity record actually lives, where “can this person open the app” gets decided, where “can this person see this specific field” gets decided, and where you go to answer “who did what, when” after something goes wrong.
The reason this mapping matters and isn’t just vocabulary trivia: identity teams don’t run one tool. Research from Omdia analyst Todd Thiemann, covered by TechTarget, found that identity teams use an average of 11 tools for workforce identity security alone, commercial, open source, and homegrown, combined. An AWS practitioner walking into a Ping deployment isn’t walking into one unfamiliar product. They’re walking into a stack, and the stack has a shape. The shape is the useful part. Once you see it, five product names stop being five things to memorize and become five familiar jobs wearing new name tags.
The five-layer map
Every identity decision an AWS environment makes, whether you noticed it as “IAM” or not, resolves into one of five jobs:
- Directory: where the identity record lives, independent of what it’s allowed to do.
- Trust: which outside authorities you accept assertions from.
- Enforcement: can this identity reach this app or API at all (coarse-grained).
- Authorization: given access, what does this identity actually get to see or do (fine-grained).
- Control plane: where you administer the system and see what happened.
AWS runs all five inside one product family, mostly under the IAM and CloudTrail umbrella, because AWS is both the authority and the resource for everything living in your account. Ping’s product line runs the same five jobs as five more separable pieces, because Ping is usually brokering trust between parties who don’t share an account, or even a company.
| Layer | AWS practitioner’s mental model | Ping equivalent |
|---|---|---|
| Directory | IAM user record / AWS Managed Microsoft AD entry | PingDirectory entry, or a PingOne population record |
| Trust | IAM identity provider object + role trust policy | PingFederate SP/IdP connection (or PingOne’s built-in OIDC/SAML IdP support) |
| Enforcement | IAM policy attached to a role, evaluated per API call | PingAccess policy on a protected application or API |
| Authorization | Resource-based policy conditions (aws:ResourceTag, etc.) or Amazon Verified Permissions | PingAuthorize policy, evaluated per request/field |
| Control plane | IAM console + CloudTrail | PingOne admin console + per-environment audit log |
Notice the last pair already telling on itself. AWS’s box says “one place to see it all.” Ping’s says “several places.” That’s not a diagram error, it’s the first honest difference between the two models, and it’s worth sitting with before writing off the rest of the map as a naming exercise.
Walking the five layers
Directory. An IAM user is, at bottom, a named record representing a person or a workload, decoupled from what it’s allowed to do until a policy gets attached. PingDirectory does the same job: a high-performance LDAP-backed store built to hold identity records at scale, which PingAccess and other Ping products query for attributes at policy-decision time. PingOne’s built-in directory does the cloud-native version of the same thing, organized into populations, for example an Employees population and a separate Contractors population, the same instinct as putting a subsidiary’s workloads in their own AWS account instead of your primary one.
Trust. Already covered in depth elsewhere, so briefly: an IAM identity provider object plus a role’s trust policy is what tells AWS which outside authority’s assertions to accept. PingFederate is the dedicated, self-managed product for exactly that job, brokering trust across parties that don’t share infrastructure. PingOne can also act as an IdP or SP directly for simpler cases. If you want the protocol-level version of this mapping, that’s the other post.
Enforcement. This is where IAM policy evaluation happens on every API call: does this role’s policy allow this action on this resource, yes or no. PingAccess is the product built for this exact decision at the application and API layer. It sits in front of a protected app as a reverse proxy or agent, and for every request it answers one question: is this identity, carrying these groups and these session attributes, allowed to reach this app at all. It can query PingDirectory over LDAP or REST for attributes it doesn’t already have on the token, group membership, department, clearance level, the same way an IAM policy condition reaches for a resource tag.
Authorization. Here’s where the AWS model and the Ping model structurally diverge, not just rename. A single AWS IAM policy document can express both a coarse rule (can this role touch this S3 bucket) and a fine one (only if aws:ResourceTag/classification equals public) in the same JSON document, evaluated by the same engine. AWS’s own ABAC documentation walks through exactly this pattern: attribute-based conditions layered on top of ordinary IAM policy. Amazon Verified Permissions, built on the open-source Cedar policy language AWS released in 2023, goes further and externalizes that fine-grained decision into its own dedicated service.
PingAuthorize is Ping’s version of that same externalized, fine-grained decision, evaluated separately from PingAccess and usually later in the request path, often between an application and the data it’s about to return. Where AWS gives you the option to fold coarse and fine grain into one policy engine, Ping’s architecture makes the split structural: PingAccess decides whether you’re in the building, PingAuthorize decides what’s actually visible on the page once you are.
Control plane. IAM console plus CloudTrail is one interface backed by one account-wide (or Organization-wide, via CloudTrail Organizations) log, covering every principal’s every action by default. PingOne’s admin console covers environments, populations, groups, and administrator roles, and exposes a Read Audit Activities API plus per-environment log streaming to a SIEM. But that coverage is scoped to what’s happening inside PingOne itself. PingFederate, PingAccess, and PingDirectory, when run in Ping’s self-managed software deployment model rather than the PingOne SaaS, keep their own local audit logs, and shipping them anywhere is your job. Ping’s documentation describes a PingFederate audit-log workflow built around exporting to an intermediary storage bucket as CSV, not a built-in cross-product query, though the exact current mechanism needs confirming against the live docs before publish rather than taken as settled here. Four products, four owners, four logs, unless somebody wires them together on purpose.
A worked scenario: the Harborview transition
Meridian Financial (the fictional carrier this site’s IaC posts are built around) acquires a smaller regional carrier, Harborview Mutual. Forty Harborview claims staff need to work inside Meridian’s claims portal during the integration period, without being forced onto Meridian’s own HR pipeline on day one.
Directory. Meridian’s identity team creates a PingDirectory population, harborview-transition, separate from the main employees population. Same instinct as standing up a dedicated AWS account for an acquired subsidiary instead of merging directories immediately.
Trust. PingFederate is configured with a SAML SP connection trusting Harborview’s existing on-prem ADFS as the IdP, so Harborview staff keep authenticating with the credentials they already have. The connection maps the incoming SAML attribute department=Claims onto membership in a PingOne group, ClaimsProcessors-Harborview, at the moment of federation.
Enforcement. PingAccess protects the claims-portal app with one rule: allow if the session carries ClaimsProcessors-Harborview or ClaimsProcessors-Meridian group membership, deny otherwise. That’s the whole coarse gate. Can this person open the app.
Authorization. Once inside, PingAuthorize evaluates every claim-record request against policy claim-record-access-v4: a claims processor may view a claim only if resource.assigned_adjuster_id == subject.employee_id, unless subject.groups includes SeniorAdjuster. A second rule masks the ssn and bank_routing_number fields on any response unless subject.groups includes FraudReviewer and resource.fraud_flag == true.
Control plane. Three months in, a security review asks the obvious question: did any Harborview claims processor ever see an SSN they shouldn’t have? Answering it means pulling four separate logs. PingFederate’s log shows who authenticated through Harborview’s ADFS, and when. PingOne’s log shows which groups their session carried. PingAccess’s log shows which claims-portal requests they made. PingAuthorize’s log shows which field-masking decisions applied to those requests. Then you correlate all four by session ID and request ID, across four independently owned log stores. In an all-AWS version of this same scenario, coarse access decisions land in one CloudTrail table by default. Getting the same field-level masking decisions into that table takes deliberate work too: authorization built through something like Amazon Verified Permissions, plus the right data-event logging turned on, neither of which is automatic. The gap between the two models is real. It’s just smaller than it looks. Ping starts you with four logs on day one. AWS starts you with one that doesn’t cover everything either. Someone still has to build the pipeline that makes the full picture exist, on either side.
Misconceptions worth killing directly
“Ping is basically IAM for other companies.” No single Ping product does what IAM alone does. The job IAM does in one engine is deliberately split five ways across PingDirectory, PingFederate, PingAccess, PingAuthorize, and PingOne.
“PingOne is just the newer version of PingFederate.” They’re not a before-and-after, they’re two different deployment models doing complementary jobs, PingOne as the multi-tenant SaaS control plane, PingFederate as a self-managed federation server, and real deployments frequently run both together: PingFederate brokering trust with an on-prem partner, PingOne hosting the cloud-side policy and directory layer on top of it.
“PingAccess and PingAuthorize are the same thing at different scales.” They enforce at different points in the request path, not different sizes of the same decision. PingAccess answers “can this identity reach this app or API at all.” PingAuthorize answers “given that it can, what does this specific response actually contain.”
“Ping consolidated into one product line once ForgeRock merged in.” Not as of 2026. PingOne and PingOne Advanced Identity Cloud (formerly ForgeRock Identity Cloud) are still two distinct platform families, with cross-product integration ongoing rather than finished. If you’re mapping a Ping environment and it doesn’t match this post cleanly, check which family you’re actually looking at before assuming the mapping is wrong.
Where the map breaks: “role” means two different things
Here’s the tension this mapping doesn’t resolve cleanly, and shouldn’t pretend to.
In AWS, a role is an identity. It’s a principal you assume, with a trust policy governing who can assume it and a permission policy governing what it can then do. When an AWS-trained architect hears “set up the role” in a federation context, they reach for exactly the right instinct: define who can become this identity, and what it gets once it does.
PingOne also has “roles,” documented right there in the Administrator Roles guide: Environment Admin, Identity Data Admin, Client Application Developer, and so on. These are not identities you assume. They’re permission sets assigned to an existing administrator, scoped to an organization, environment, or population. Closer to what AWS would call a managed policy, or a permission set in IAM Identity Center, than to an IAM role.
So the AWS-trained instinct walks straight into a wall: go looking for the object that governs who this workload becomes when it federates in, expecting to find it under “Roles” in PingOne, and find PingOne’s admin-permission system instead, which governs who can administer the PingOne console, not who a workload gets to be. The actual trust-establishing object, the one that does what an IAM role trust policy does, lives in PingFederate’s connection configuration, an entirely different part of the product line, not called a role at all.
This isn’t a misconception to correct with a clean rule. Both systems are going to keep using the word “role,” they mean genuinely different things by it, and there’s no vendor-side fix coming. The only real mitigation is discipline: every time the word “role” shows up in a design conversation, stop and ask which system you’re in before writing anything down. It’s a small thing to get wrong and an expensive one, because it usually surfaces as a design document that describes a trust relationship using the wrong product’s object model, reviewed and approved by people who didn’t catch the substitution either.
The analogy: a hospital wristband, not an office badge
A hospital works the same five-layer shape, and the stakes make the split obvious in a way an office building doesn’t.
Registration issues you a wristband when you’re admitted. That’s the directory record, who you are, independent of what floor you’re allowed on. If you arrive transferred from a partner hospital under a standing referral agreement, the ER checks your transfer paperwork against that agreement before treating you as one of theirs, not from scratch: that’s trust, a federation connection with an outside authority the hospital already recognizes. Every unit door, maternity, ICU, psych, has its own badge reader deciding one binary question: is this credential cleared for this floor. That’s enforcement, coarse-grained, at the door. Getting through the door doesn’t mean you see the whole chart. The chart system itself decides whether a floor nurse can open a patient’s vitals but not their psych evaluation, unless they’re specifically on that care team: that’s authorization, fine-grained, evaluated per field, after the door already let you in. And when something goes wrong, the ER’s sign-in sheet, the pharmacy’s dispensing log, and the OR’s access log are three separate systems, kept by three separate departments, that were never designed to answer a cross-department question about one patient’s day without someone deliberately pulling all three and lining them up by timestamp.
Nobody would look at that hospital and conclude the ER, the badge system, and the chart system are all “basically the same thing.” They’re not. They’re five jobs, done by five systems, on purpose, because the consequences of collapsing them into one system are worse than the friction of keeping them separate. That’s the actual argument for why Ping’s product line looks the way it does. It isn’t scattered. It’s specialized, the same way a hospital is.
Security note
The split between PingAccess and PingAuthorize isn’t organizational overhead, it’s a real security property: it lets the edge fail closed even if the fine-grained layer has a bug, because the coarse gate is a separate enforcement point that doesn’t depend on the fine-grained one being correct. But that property only exists if both layers are actually deployed. A lot of real PingAccess-only rollouts skip PingAuthorize and let the application’s own code do field-level masking in-house, which quietly reintroduces exactly the kind of undocumented, unaudited in-app authorization logic that externalized authorization, PingAuthorize, Amazon Verified Permissions, OPA, exists to eliminate in the first place. If you’re reviewing a Ping deployment and PingAccess is there but nothing is doing the PingAuthorize job, ask where the field-level decisions actually live. The honest answer is usually “in the app,” and that’s the same finding a code review would flag in an AWS shop rolling its own row-level security instead of using a resource policy condition.
