Hey folks — been tinkering with Ping’s geo-based access rules for a client project and wanted to share our step-by-step setup. We had a requirement to block access from certain countries for compliance reasons, while allowing specific IPs from those regions (think contractors or traveling employees). Here’s how we pieced it together using PingFederate and PingAccess.
First, we mapped out the logic:
- Default policy: deny access from a blocked country list.
- Exception: allow if the IP matches a whitelist (even if from a blocked country).
- Fallback: if geo-IP lookup fails, require step-up authentication (better safe than sorry).
The core configuration happened in PingAccess:
1. **Created a new policy** under Access Control → Rules.
- Used the “Location” condition set to pull from the MaxMind GeoIP2 database (Ping has built-in support).
- Added countries like `RU`, `CN`, `BR` to the “blocked” list.
2. **Built an IP whitelist** as a separate rule.
- Added CIDR ranges for our known safe IPs (e.g., corporate VPN exit nodes).
- Set the rule order so the whitelist evaluates *before* the country block.
3. **Added a final catch-all rule** for “unknown” locations that triggered a second-factor prompt.
A couple of things we learned the hard way:
- The order of rules is critical — PingAccess evaluates top-down, so whitelists need to be higher up.
- Geo-IP data isn’t perfect. We saw some legitimate users flagged incorrectly, so we added a low-friction “report access issue” link that logged their IP for review.
- If you’re using cloud proxies (like Cloudflare), make sure Ping is configured to use the original client IP header, not the proxy’s IP.
Has anyone else set up something similar? Curious how you handled:
- Users who travel frequently — did you create a self-service portal for temporary access requests?
- Performance impact — we didn’t see latency spikes, but our traffic volume is moderate.
Overall, it’s been solid for about six months. The logging is detailed enough to audit, and we’ve avoided any compliance headaches. Definitely recommend testing in monitor-only mode first if you can.
✌️
✌️
Your rule order is critical. If the whitelist isn't first, the geo-block will hit first and deny the whitelisted IPs from blocked countries. We learned that the hard way during testing.
Don't forget to set up logging for the "unknown" catch-all rule. You'll need to monitor those events closely. A high volume usually means your GeoIP data source is outdated or the lookup is failing.
What step-up method did you use for the fallback? SMS OTP? We had latency issues with that and switched to a hardware token prompt.
Prove it with a benchmark.
Good outline. The whitelist ordering note is critical.
You mentioned the catch-all for unknown locations. I'd make that rule log at DEBUG level and alert on any hits. A sudden spike means your GeoIP data feed broke.
Hardware token for the fallback is the right call. SMS OTP is a compliance nightmare waiting to happen.
slow pipelines make me cranky
You've covered the core sequence well. Building the whitelist rule before the country block is the most common, and critical, pitfall to avoid.
One nuance to consider is the performance overhead when scaling. The MaxMind lookup for every request, while necessary, adds latency. On a high-traffic gateway, you might see a 2-5ms penalty per request. We've mitigated this by implementing a small, in-memory cache for recently resolved IPs within PingAccess, which drastically cuts down on repetitive lookups for recurring user sessions.
For the catch-all "unknown" rule, we configured it to route to a separate authentication fragment requiring a client certificate, which serves as our step-up. It's heavier than SMS OTP but provides a non-repudiable audit trail, which our compliance team demanded.
That's a great point about the cache. We found the exact same latency hit on our ingress. For the cache, did you implement it as a custom policy fragment, or is that a built-in option now? We ended up doing a small in-memory LRU cache via a scripted rule, but I'm curious if there's a more official method.
The client cert for the unknown fallback is smart. The audit trail is worth the setup complexity, especially for financial services. Did you run into any issues with certificate distribution for your approved-but-unknown-location users? Managing that lifecycle seems like it could become its own beast.