Hi everyone. I've been diving deep into our auth flows after a security review flagged some high-value admin actions as only requiring basic password auth. My team uses PingFederate with PingID for MFA, and step-up authentication was the obvious answer. The documentation is... comprehensive, but piecing together the *practical* step-by-step for a real deployment had me going in circles for a bit.
I finally got a clean flow working: a user tries to access a protected resource, gets their first factor validated, and then is prompted for a PingID verification *only if* the application's policy demands it. The key was getting the PingFederate authentication policy contract and the PingID adapter to handshake correctly.
Here’s the sequence that worked for us:
1. **Define the Authentication Policy Contract (APC) in PingFederate.** This is where you specify the "Step-Up" requirement. You create a new APC that includes both "PingID" and your primary adapter (like "Username/Password"). The trick is the "Authentication Source" setting—you need to set it to "Step Up" so it doesn't re-prompt for the first factor.
2. **Map the APC to your PingID Adapter Instance.** In the PingID adapter configuration, you select the new Step-Up APC. This tells PingID, "When you're invoked for this policy, you're the second step."
3. **Create the Step-Up Authentication Policy.** This is the rule that triggers the flow. You set the context (like a specific application or URL path) and then select your Step-Up APC as the requirement. The critical part here is the "Authentication Requirement" option—you must choose "Step Up" and reference your primary authentication session. This is what prevents a full re-auth.
The main pitfall I hit was the session handling. If the primary auth session isn't correctly referenced, the user just gets thrown into a full PingID prompt from the start, which is a bad experience. Also, making sure your application is actually passing the correct authentication request context (like using `authnChain` or step-up parameters in the SAML request) is crucial.
Has anyone else implemented this recently? I'm particularly curious about how you handled timeout scenarios for the step-up—do you let the primary session expiry invalidate the step-up, or do you manage separate timeouts? The interplay there feels like it could get complex.
Interesting. So you're saying the entire "cost" here is just developer time spent piecing together documentation? I don't see any hard numbers on how this actually saved anything.
What's the operational expense of running the PingID adapter instances now? Did your compute needs change? There's always a hidden tax for adding complexity to an auth flow. I'd be curious to see if your cloud bill's "Other" category crept up after this deployment, or if you're just trading one kind of risk for a different, more expensive one.
cost_observer_42
Great start on outlining the APC setup. One thing I'd add from doing this for clients: make absolutely sure your session policy is configured to *not* invalidate the initial authentication source when the step-up is triggered. I've seen deployments where the base password session gets cleared, forcing a full re-auth, which completely breaks the user experience. PingFed's session behavior there isn't always intuitive.
Integrate or die
Nice! That APC setup is the heart of it. Your point about the "Authentication Source" being set to "Step Up" is critical. The first time I configured one of these, I missed that dropdown and set it to "Primary". Queue the angry user tickets because they had to type their password again for the step-up prompt. It felt like a regression.
Another little gotcha: watch your session expiration times between the first factor and the step-up. If the password session is set to 10 minutes and the step-up policy is 60, you can get some weird, silent failures in the flow. Ask me how I know! 😅
Got any examples of how you're triggering the step-up? Via a specific application policy or are you using the API?
it worked on my machine
That's a solid foundational walkthrough. The real latency cost gets buried in step two, when mapping the APC to your PingID adapter instance. If you're using the PingID cloud service, the network hop for that verification request adds a hard 80-120ms floor to your transaction, which doesn't appear in the admin console's policy configuration view.
You can mitigate it by enabling the adapter's local cache for successful validations, but then you have to tune the TTL against your organization's acceptable risk window for a potentially compromised device.
--perf