Hey folks. Looking at identity providers for a healthcare client and the compliance overhead is significant. We need something that can handle HIPAA's BAAs, audit controls, and strict access management out of the box, without us building a fortress from scratch.
PingOne seems to be a strong contender in this space. From a pipeline and infrastructure perspective, I'm interested in how it integrates into a typical healthcare app deployment. Specifically:
* **Automated User/Group Provisioning:** How well does SCIM sync work with existing HR systems? Any quirks in the API when automating this?
* **Deployment & Configuration as Code:** Can the entire setup (policies, applications, connections) be managed via Terraform or similar? We want our IdP config in version control.
* **Audit Log Integration:** How easy is it to pipe those critical auth logs into our centralized SIEM (likely something like Splunk or Azure Sentinel) for compliance reporting?
* **MFA Enforcement:** Does it smoothly handle strong authentication (like WebAuthn/physical tokens) for both internal staff and external patients/portal users?
Here's a snippet of the kind of GitHub Actions workflow we'd need to automate testing a configuration change, for example:
```yaml
name: Validate PingOne Configuration
on:
pull_request:
paths:
- 'pingone-terraform/**'
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: hashicorp/setup-terraform@v3
- run: terraform -chdir=pingone-terraform init && terraform plan
env:
PINGONE_CLIENT_ID: ${{ secrets.PINGONE_CLIENT_ID }}
PINGONE_CLIENT_SECRET: ${{ secrets.PINGONE_CLIENT_SECRET }}
```
Has anyone here gone through a similar evaluation or, better yet, a full implementation? I'm keen to hear about the real-world operational experience—pitfalls with scaling, unexpected costs, or areas where the automation story fell short. Bonus points for any experience with Kubernetes ingress/auth integrations (like using the PingIdentity sidecar or OIDC with Istio).
Build fast. Fail fast. Fix fast.
Good breakdown. On the deployment-as-code question, PingOne does have a Terraform provider, but its coverage is often incomplete for newer features or granular policy settings. You'll likely end up with a hybrid approach: core resources in Terraform, but nuanced policy JSON managed via their API and your own scripts.
For audit log integration, their API for exporting events to a SIEM is solid, but the real work is mapping their event taxonomy to your SIEM's schema. You'll want to build a small transformation layer, maybe in a Logic App or a Python lambda, before the logs hit Splunk to ensure compliance officers can actually run reports.
Regarding MFA, their handling of WebAuthn for external users can be clunky if you need granular policies differentiating staff from patients. The policy conditions aren't as flexible as something like Okta's, so test that workflow exhaustively before committing.
IntegrationWizard
That audit log mapping layer is a compliance gotcha. We built ours as a scheduled Azure Function, not a Logic App. It's more reliable for high volume, but you're right, the taxonomy mismatch is the real problem. Ping's events for "policy evaluation" versus actual "access denied" are separate log streams, which tripped us up.
Their Terraform provider gaps are a liability for HIPAA. If a policy setting isn't covered, you can't prove the infrastructure state is immutable. We had to treat any non-Terraform managed config as a deviation requiring a written control exception. It added a ton of paperwork.
The MFA point about external users is critical. For patient portals, we had to implement a separate Ping environment altogether because the policy conditions couldn't scope cleanly within a single org. That doubled the audit surface.
Where is your SOC 2?
PingOne's SCIM implementation is generally reliable for core HR sync from systems like Workday. The quirk you'll run into is with custom attributes or complex nested groups, where the API can be inconsistent. We built a small middleware service to normalize payloads before SCIM pushes, which added a layer of complexity but solved the sync failures. Their rate limits are also quite aggressive for bulk operations.
For your GitHub Actions snippet, you'll likely be using their API directly for any provisioning steps beyond basic CRUD, as their Terraform provider's SCIM resources are limited. I'd recommend treating the IdP provisioning as a separate pipeline stage with its own error handling and audit trail.
On the point about strong MFA for external patients, we found Ping's policy engine lacked the conditional logic to cleanly separate staff and patient flows without creating entirely separate environments, as user323 mentioned. That architectural decision doubled our BAA scope and compliance validation effort.
PingOne can handle the HIPAA BAA and basic controls, but you will absolutely build a fortress from scratch around it. The out of the box promise doesn't survive contact with real automation and compliance reporting needs.
On your specific points: Their SCIM works until it doesn't. The API will choke on complex group memberships from a legacy HR system, and you'll spend months building and maintaining that middleware normalization layer others mentioned. Their Terraform provider is a compliance risk. If a critical MFA policy setting is only in the UI, it's not in your version control, and your auditors will write you up for it. You'll end up with a fragile hybrid of Terraform for the skeleton and custom API calls wrapped in scripts for the meat, which defeats the "as code" goal.
For audit logs, piping them to Splunk is trivial. Making them useful is not. Their event schema is built for their support team, not your compliance officer. You'll be writing and maintaining that transformation pipeline yourself, and you'll need to prove its integrity. For MFA, planning separate environments for staff and patients isn't a workaround, it's a necessity. Their policy engine lacks the surgical precision for that mix within a single tenant.
Been there, migrated that