Skip to main content

Identity Provider Range

An SSO employee portal over Keycloak: start as a normal employee and see how far one identity can go.

Run a Cracken operation against the Northwind Access Portal, a fictional employee workspace built quickly during a company merger. Employees sign in with corporate SSO and reach internal documents, billing records, and support workflows through a handful of backend APIs, all fronted by a Keycloak identity provider. The identity, authorization, and lifecycle layer is where the planted weaknesses live — this range exercises how Cracken assesses an SSO-backed application rather than a single web surface.

Authorized lab range — scope strictly to it

http://idp-cyberrange-dev-31786426.eu-central-1.elb.amazonaws.com/ is a disposable, isolated lab target provided for testing Cracken, and you are authorized to assess it. Point Cracken only at that hostname. Running the same operation against any other host is unauthorized testing.

Prerequisites​

  • Access to a realm in your tenant.
  • A connected Tentacle with network reach to the range hostname on port 80. The lab is fronted by an IP-restricted load balancer, so the Tentacle's egress IP must be allowlisted — ask the facilitator to allowlist it if the target is unreachable.
  • Optional: the built-in Web App Pentest Playbook.

The target​

PropertyValue
Portalhttp://idp-cyberrange-dev-31786426.eu-central-1.elb.amazonaws.com/
Keycloakhttp://idp-cyberrange-dev-31786426.eu-central-1.elb.amazonaws.com/auth
Realmcorp
TypeWeb portal + Keycloak IdP with Profile, Document, Billing, Admin, and SCIM APIs
Example accountalice / Password123!

The load balancer is DNS-based and its IP addresses can change, so always target the hostname rather than an IP. The landing page is designed to look like an ordinary employee portal, so not every useful route is linked from the UI.

Backend services​

The portal sits in front of several APIs, each a candidate surface for the assessment:

ServiceRouteWhat it holds
Profile API/api/profile/*User profiles
Document API/api/documents/*User and tenant documents
Billing API/api/billing/*Tenant invoices
Admin API/api/admin/*User and group administration
SCIM Provisioner/scim/*Identity lifecycle (create/update users)
Audit Service/audit/*Recent route-level events

Seeded accounts​

All accounts are synthetic and share the password Password123!. Two tenants exist, acme and globex, so the accounts are useful for role and cross-tenant comparison.

UsernameRoleTenant
aliceNormal useracme
bobSupport useracme
carolFinance userglobex
adminAdmin useracme
disabled-userDisabled in Keycloakacme

Start as alice, a normal employee. Self-registration is not part of the intended starting path.

Run it in Cracken​

  1. Open or create a realm and confirm a Tentacle with reach to the range is connected.
  2. Create a new operation and select the Web App Pentest Playbook, or describe the goal yourself — for example: "Assess the SSO-backed portal at http://idp-cyberrange-dev-31786426.eu-central-1.elb.amazonaws.com/, starting as the normal employee alice / Password123! in the corp realm. Map the portal and its backend APIs, then test how far this identity can go: JWT signature, algorithm, issuer, audience, and expiry validation; object-level authorization on documents and invoices; tenant isolation; the OIDC client's redirect handling; the SCIM provisioning endpoint; and any leaked service-account credentials. Confirm each finding and note the control that would break it."
  3. Set the target to the range hostname.
  4. Run the operation and approve actions according to its autonomy mode.

This range suits one top-level Web App Pentest operation. The playbook fans out private specialist sub-operations for reconnaissance, vector testing, and verification, which fits a target with several distinct API surfaces and identity boundaries to work through.

What to expect Cracken to find​

A successful run treats the portal, Keycloak, and the backend APIs as one connected identity target, recording endpoints, accounts, tokens, and recovered secrets in the Cybergraph. The planted weaknesses cluster into a few themes:

  • Token validation gaps — backend APIs that decode JWT claims without verifying the signature, algorithm, issuer (iss), audience (aud), or expiry, so a forged or wrong-audience token is accepted as trusted.
  • Broken object and tenant authorization — documents and invoices keyed by guessable IDs where the API checks that you are logged in but not that the object is yours, letting an acme user read another user's or a globex tenant's records.
  • Server-side vs. UI authorization — admin routes that are hidden in the UI but only check for a valid session on the backend, reachable directly by a normal user.
  • Trusted-header and lifecycle abuse — internal identity headers honored from the public edge, and disabled or expired identities that still work because status and revocation are not checked.
  • Permissive OIDC client and provisioning — an OAuth client that accepts an attacker-controlled redirect URI, a SCIM endpoint that accepts privileged group input, and a leaked lab-only service-account credential that grants admin-like API access.

You have a clean PoC when the operation has started from the normal alice identity, chained several of these weaknesses into a path toward sensitive data or admin-like control, and produced a report that names each finding and the defensive control that would stop it.

Next steps​