GBLI Authz PoC
Login
Sandbox demo

Identity is easy. Business authorization is the real design problem.

This PoC separates authentication and inline business authorization. No external rule engines.

Migration Demo

Use the same legacy identity through each stage. Keycloak decides which upstream IdP to use while the app continues to see the same business user.

Stage 1: Okta is primaryStage 2: Link Authbeast onceStage 3: Route to Authbeast
StageUser doesWhat happens
1atlasAlice@legacy.local logs in with Okta password Demo1234!Keycloak routes to Okta and the app signs in as Alice Smith.
2Admin marks the same legacy user for federation, then the user clicks the link action after the Okta loginThe app starts Keycloak's supported account-link flow. User signs in once with the Authbeast account and returns to the app.
3User enters the same legacy email againKeycloak sees the Authbeast link and routes straight to Authbeast instead of Okta.

After the Stage 1 Okta login, use the Launchpad action to start the one-time Authbeast link.

Legacy identity stays the same in the app. Old and new IdPs can run side by side during migration. Okta can be removed later after users are linked.

Demo users

Identity = email. All local users authenticate in the Keycloak broker realm.

IdentityPurposeSetup
ann.rivera@gmail.comAtlas agent — policy access via membership.Mailpit link.
brian.cho@gmail.comAtlas underwriter — assignment and approval.Mailpit link.
carla.ng@gmail.comAtlas billing specialist — billing scenarios.Mailpit link.
dan.lee@outlook.comSummit agent — cross-agency denial cases.Mailpit link.
mail.idp.pavels.jelab.orgPublic Mailpit inbox.Open message and follow link.

Components

Keycloak = authenticationOrg API = business dataAuthz = inline rules

Policy Workspace for authorization stories, Billing Desk for role separation, Org Viewer for data, Decision Viewer for traces.