We're evaluating Ping Identity against Okta and Azure AD for a central IAM at a large public university. Our environment is hybrid: legacy on-prem apps, SaaS (Canvas, Office 365, research portals), and a growing k8s-hosted microservices layer. Scale is 50k+ identities, with high seasonal churn (new students, adjunct faculty).
Our core requirements:
* **Lifecycle Management:** Automated provisioning/deprovisioning from our SIS and HR systems.
* **Access Federation:** SAML 2.0 and OIDC for everything. Must handle app-specific attribute release.
* **Developer Experience:** Clean APIs and maybe Terraform provider for us to manage resources as code.
* **Operational Clarity:** Detailed audit logs, integration health dashboards, and clear alerting.
The shortlist is down to PingOne and PingFederate. I'm skeptical of running our own PingFederate clusters, but the cloud offering needs to prove it can handle our complex, nested group structures for role-based access without performance hits during peak login periods (first week of term).
Has anyone run Ping at this scale in education? I need real pipeline data, not sales sheets.
Specific questions:
* What does the Terraform/PingOne module coverage look like for real-world config? Can I define an identity policy as code, or is it all click-ops?
* How are the logs for troubleshooting a failed OIDC flow? Do they give you raw SAML responses or just "authentication failed"?
* Any major pitfalls with custom attribute synchronization from on-prem LDAP?
-shift
shift left or go home
PingFederate on-prem is a full time job for a team. You're right to be skeptical. The ops overhead for patching, scaling, and DR for 50k identities will eat your lunch, especially with term start spikes. The cloud offering abstracts that away, but you're trading control for black box behavior.
I've seen PingOne choke on nested groups past five levels when you're pushing attribute release to hundreds of SAML apps at peak load. The logs show it, but the dashboard stays green. You need to test your actual group depth and login concurrency, not their canned demo.
For pipelines, get them to show you real audit log volume and search performance for a 24 hour period during term start from another edu client. The API rate limits on their Terraform provider are also a real constraint for bulk changes during your seasonal churn.
Don't panic, have a rollback plan.
That seasonal churn with 50k identities is a huge factor you're right to focus on. I've seen a similar setup where the daily provisioning/de-provisioning jobs from the SIS became the biggest bottleneck during add/drop period, not the login spikes.
For your question on nested groups in PingOne - yes, it can struggle. We built a separate "role flattening" service that pre-processed our insane group hierarchy from the HR system before sync. It was extra work, but it kept performance stable during those first-week rushes.
On the Terraform provider: test the API rate limits with a bulk simulation of your term-start onboarding. We hit soft limits that weren't in the docs and had to batch our config updates. The audit log search can also get sluggish under heavy load, so make sure your security team's use cases are covered during a spike scenario.
null
Ran PingFederate for a 30k user edu org for three years. The Terraform provider for PingOne is usable, but you'll hit its limits doing bulk term-start syncs. You'll need to script batching around the API rate limits.
For your scale and churn, I'd lean cloud for the ops burden alone, but you're right to test nested groups. We had to flatten our directory tree before sync. The audit log volume during peak will be massive; make sure you can export and pipe it to your own Loki or SIEM for real query performance.
Have you looked at the actual concurrency numbers for your research portals during first week? That plus attribute release logic often trips things up more than total user count.