How to use. Switch the conditions below: the verdict the lookup stand-in gives your address, and whether the account is exempt from the address checks. Then open a scenario, sign in, and compare what happens with its matrix: the outlined cell is what the current conditions should give. Signing out ends the Keycloak session too, so the next sign-in is a fresh login rather than a returning session.
Your address 216.73.216.102: verdict none (no entry: the stand-in answers 404). The account's exemption: off. Read-only: only the lab's control addresses can change the conditions.
No flow override and no attributes: the realm's own browser flow, which ends both the fresh-login and the returning-session path with the geo guard. Shows the guard's four answers with the exemption off, and that the exemption skips it.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
The realm's flow with geo.vpn.guard.ip.bypass = 0.0.0.0/0,::/0, exactly what a client's geo_guard: false produces. Shows that an opted-out client admits every address and verdict, exempt or not, without a lookup.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | admitted | admitted | admitted |
The realm's flow with geo.vpn.guard.ip.bypass = your address/32, what geo_guard_bypass_cidrs gives a client (F5-stage keeps such a list for its egress). Shows that a listed address skips the lookup whatever it geolocates to.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | admitted | admitted | admitted |
browser-oidc-group-restricted with restrict.to.group = qiwaDevOpsSuper, a group the account is in. The group check passes, so the outcome is the geo guard's, which ends this flow too.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
browser-oidc-group-restricted with restrict.to.group = qiwaDevOpsProd, an existing group the account is not in. Refused QA015 in every condition: the group check ignores the exemption and runs before the geo guard, so no lookup is made.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | QA015 | QA015 | QA015 | QA015 |
| not-exempt | QA015 | QA015 | QA015 | QA015 |
As group-not-member, with restrict.to.group.error set to the text 19 production clients carry (grafana-prod among them). Shows the operator's text on the denial page with the code still in front: QA015: Sorry!, You're not authorized to access this client.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | QA015 | QA015 | QA015 | QA015 |
| not-exempt | QA015 | QA015 | QA015 | QA015 |
browser-oidc-group-restricted with restrict.to.group naming a group the realm does not have. Shows that a mistyped group fails closed, QA015 for everyone, rather than opening the client.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | QA015 | QA015 | QA015 | QA015 |
| not-exempt | QA015 | QA015 | QA015 | QA015 |
browser-oidc-group-ip-restricted with restrict.to.ip = your address/32 and no group named. The address check passes, so the outcome is the geo guard's.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
browser-oidc-group-ip-restricted with restrict.to.ip = 203.0.113.0/24, a documentation range that is never your address. Refused QA020 before the geo guard with the exemption off; admitted with it on, because ipPolicyExempt also exempts from the client address allowlist once the user is known.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | QA020 | QA020 | QA020 | QA020 |
browser-oidc-full-restricted (the per-user check is only in the full flows) with only restrict.to.user.ip = true. The account has no allowedIps, which means unrestricted, so the check admits and the outcome is the geo guard's; QA025 would need an allowedIps value on the account.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
browser-oidc-full-restricted with the group (qiwaDevOpsSuper), the client address list (your address/32) and the per-user list switched on. The account passes all three, so the outcome is the geo guard's, which comes last.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
A SAML client on browser-group-restricted with restrict.to.group = qiwaDevOpsSuper, a group the account is in. The SAML twin of group-member: the check passes and the geo guard decides.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
A SAML client on browser-group-restricted with restrict.to.group = qiwaDevOpsProd, a group the account is not in. Refused QA014, the SAML code, in every condition: the check ignores the exemption and runs before the geo guard.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | QA014 | QA014 | QA014 | QA014 |
| not-exempt | QA014 | QA014 | QA014 | QA014 |
A public client (no secret) that requires PKCE S256, on the realm's flow: the shape of production's account-console. Shows that the client type changes nothing at the login: the geo guard decides, as for geo-saudi-only.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | admitted | admitted | admitted | admitted |
| not-exempt | admitted | QA023 | QA024 | QA022 |
The realm refuses to even create a client with the password grant on, so this client has it off; /password-grant tries grant_type=password with the realm's built-in admin-cli, which still has it on, and shows the policy's own answer. Refused in every condition by the realm's reject-password-grant client policy: the grant never runs the browser flow, so neither the exemption nor the verdict plays a part.
| account \ verdict | SA | GB | SA+vpn | none |
|---|---|---|---|---|
| exempt | refused | refused | refused | refused |
| not-exempt | refused | refused | refused | refused |