Hi everyone! I'm new to the identity space, coming from a basic monitoring/ops background. I'm trying to learn by doing, and just configured PingFederate to restrict access based on country.
My goal was to only allow connections from our approved regions. Here's the basic adapter policy I set up in the PingFederate admin console. I used the "CIDR" attribute in the policy.
```json
{
"policyId": "geo-restrict",
"condition": {
"attribute": "cidr",
"operator": "IN",
"value": [
"192.0.2.0/24",
"203.0.113.0/28"
]
}
}
```
It seems to be working in my lab! I'm using a GeoIP data source. But I'm wondering about edge cases - like VPNs or proxies that might obscure the real origin IP. How do you all handle that in production? Is there a more robust way to do this within Ping?
Your lab approach with CIDR lists is a solid first step, but you've correctly identified the core weakness: IP geolocation is fundamentally a guess, not a proof. The VPN/proxy problem can't be fully solved at this layer.
For production, you should treat geographic restriction as a soft control within a broader defense-in-depth strategy. It's excellent for blocking broad swathes of automated attacks from known hostile ASNs, but unreliable for strict user authorization. Consider supplementing it with a second factor that's harder to spoof, like device posture or a stricter time-based access policy.
Also, benchmark your GeoIP data source's update frequency and accuracy. The free MaxMind database can be weeks out of date on IP allocations. A paid commercial feed with more frequent updates provides a tangible, measurable improvement in blocking accuracy for critical assets.
numbers don't lie
Welcome! It's great to see someone starting with a hands-on lab like this, it's the best way to learn. You've absolutely hit on the big limitation already: VPNs and proxies will bypass a purely CIDR-based list every time.
For a more robust setup within Ping, you can layer it with other adapter context. Think about combining your geo rule with something like device fingerprinting or a known-cookie check. You can set up a policy chain where if the CIDR check passes, access is granted, but if it fails, it triggers a secondary authentication step, like sending a one-time code to a verified company email. This turns a hard block into a graduated control.
Also, a quick tip from my own testing: regularly audit the actual countries hitting your block logs. You'll often find traffic from unexpected CIDRs that belong to big cloud providers (AWS, Google Cloud) used by your own legitimate remote employees. You'll need to make granular exceptions for those, which gets tedious but is necessary. What GeoIP data source are you using for your lab, out of curiosity?
Your lab setup is good for a basic filter. The real test is how your GeoIP source performs under load. I've benchmarked several feeds and found latency spikes of 200-300ms on the policy decision when using external lookups.
For VPN detection, consider adding a policy condition that checks the ASN number, not just the IP range. Many commercial VPN providers use a predictable set of autonomous systems. You can combine that with a velocity check - multiple failed auth attempts from different CIDRs but the same ASN often signals a VPN pool.
Your JSON condition will work, but monitor the performance impact in your logs. Look for `policy.evaluation.time` entries. If it creeps above 100ms, you might need a local cache for the GeoIP data.
BenchMark
Good start, but those CIDR blocks in your JSON are RFC 5737 documentation addresses. You're not actually filtering real traffic in your lab. You need to use real public IPs.
For VPNs, you can't fully block them at this layer. Add a velocity check policy downstream. If you see 5 auth attempts from 5 different countries in an hour, flag it.
Also, your GeoIP source matters. MaxMind free vs paid has a big accuracy delta. Test with some known VPN exit nodes.
Benchmarks or bust.
The graduated control model you've described is architecturally sound, but its operational cost is often underestimated. Shifting from a hard block to a step-up authentication flow introduces significant overhead: you're now responsible for managing the OTP delivery mechanism, its reliability, and the helpdesk volume for employees who trigger the secondary step from legitimate but unexpected locations.
Your point about cloud provider CIDRs is critical. That granular exception list doesn't just get tedious, it becomes a security liability if not treated as formal configuration. I've seen teams manage those IP ranges in a spreadsheet, leading to drift from the actual cloud provider's published IP list. The maintenance burden usually justifies integrating a dynamic feed or API for these trusted provider ranges, rather than manual updates.
What's your method for auditing the efficacy of the step-up flow? Simply measuring blocks misses users funneled into the secondary auth. You need to track the ratio of successful step-up authentications to initial geo-failures to see if your controls are catching noise or causing friction for legitimate patterns.
Nice lab setup! Starting with the Ping admin console is the right move. You've already spotted the main issue - VPNs will slip right through a simple CIDR list.
One thing I've done is combine the geo policy with a separate "known network" check. For example, I'll allow full access from our corporate office IPs (static), but if the request comes from a "new" country, it triggers a step-up like a push notification. This way, my legit users on vacation can still get in.
Also, definitely replace those RFC 5737 addresses in your test JSON with some real public IPs from a service like ipinfo.io. It'll make your lab tests more realistic. Happy to share a quick Ansible playbook I use to pull and format real CIDR blocks for testing if you want it
Infrastructure as code is the only way