Introduction

ALDAR Bridge Integration Guide

ALDAR Bridge is Aldar's central identity & application hub. It runs the Azure AD (employees) and ForgeRock (suppliers) sign-in flows once, holds the resulting session, and hands every other application a ready-made, authenticated user — so individual apps never build their own login.

This site is the playbook for wiring a new application into ALDAR Bridge. It is written to be followed end-to-end, and it uses the real migration of the Estimation AI app (estimateai) — from a self-hosted Azure AD / JWT login to ALDAR Bridge SSO — as the worked example throughout.

New here? Follow Local Dev Setup → Frontend Integration → Backend Integration. ALDAR Bridge was formerly known as Cockpit; you may still see the cockpit name in API paths, env vars, and repository links — those wire-level identifiers are unchanged.

Request access

Start here: fill in your application's details and click Copy request email — it formats a ready-to-send registration request (subject + body) and copies it to your clipboard to paste to the ALDAR Bridge team.

New request
ToABbridge.gb@gapblue.com

Subject: New ALDAR Bridge app registration — …

Hi @Bridge Team,

We'd like to register a new application in ALDAR Bridge — this app. It runs at , scoped to . Categories: .

Please return the app_id and a service token (APP_TOKEN) for backend email & notifications.

Reply-to email (optional):

Regards,

Formats a request email to your clipboard
Open in email

What "integrating with ALDAR Bridge" means

Your app stops owning authentication and instead trusts a shared session:

  1. No login screen in your app. When a user hits a protected route with no ALDAR Bridge session, you redirect the browser to ALDAR Bridge. ALDAR Bridge signs them in and redirects back to your app.
  2. A shared session_id cookie. ALDAR Bridge sets an httpOnly cookie on a parent domain (e.g. .gnie.ai locally, .aldar.com in prod). Because it is scoped to the parent domain, the browser sends it to your app too.
  3. Identity from one endpoint. Your frontend calls GET /api/v1/cockpit/me?app_id=<id> to learn who the user is and which roles they hold for your app.
  4. Backend validation against shared Redis. Your API validates each request by reading the session_id cookie and looking the session up in the same Redis that ALDAR Bridge writes to — no JWT of your own.

What you get

CapabilityProvided by
Azure AD + ForgeRock sign-inALDAR Bridge
Single sign-on across all Aldar appsShared session cookie
User identity (id, email, name, provider)/cockpit/me
Per-app roles/cockpit/me?app_id= (configured in ALDAR Bridge admin)
Profile picture/cockpit/me (profile_picture)
Session lifetime / sliding expiryALDAR Bridge + shared Redis

What stays yours

ALDAR Bridge answers "who is this, and can they open my app?" Everything app-specific stays in your app:

  • Fine-grained authorization (per-record / per-segment grants, feature flags).
  • Your own database, business logic, and API.
  • Your UI and routing.
⚠️

You need an app_id registered in the ALDAR Bridge admin panel before roles will resolve. Ask the ALDAR Bridge team. Until then, /cockpit/me returns the user with an empty roles array.

The five things every integration touches

#ChangePage
1Point VITE_COCKPIT_API_BASE_URL + VITE_APP_ID at ALDAR BridgeFrontend
2Fetch identity from /cockpit/me; redirect to /login/direct on 401Frontend
3Send credentials: 'include' on every API callFrontend
4Validate the session_id cookie against shared RedisBackend
5CORS allow_credentials + a cookie domain both apps shareBackend
Local Dev Setup