Skip to content

Access and Roles

Portal Entry Points

Portal URL Primary Role Families Current Test Evidence
Customer Portal https://customer.test.emali2.damplabs.com CUSTOMER Verified on 2026-03-25 with customer1 / password
Organization Portal https://org.test.emali2.damplabs.com ORG_ADMIN, ORG_USER, agent and merchant org-linked roles Route behavior verified; seeded org credentials in current docs did not authenticate successfully during this refresh
Service Provider Portal https://admin.test.emali2.damplabs.com SYSTEM_ADMIN, SERVICE_PROVIDER, support and finance specializations Verified on 2026-03-25 with admin1 / password
Reporting Portal https://reports.test.emali2.damplabs.com reporting roles Existing guide set
Developer Portal https://devportal.test.emali2.damplabs.com developer roles Existing guide set

Authentication Model

All public web portals use centralized identity and shared SSO session management.

  1. Open the portal URL for the workspace you need.
  2. Click Continue or Continue With Password if the portal shows an intermediate handoff screen.
  3. Complete the Keycloak sign-in flow.
  4. If the account satisfies the portal's role and context checks, the app redirects into /app.
  5. If the account is authenticated but lacks the required portal context, the app redirects to /forbidden.

Role and Scope Rules

Portal Role Scope Behavior
Customer Individual customer profile and wallets A customer can only see their own wallets, loans, statements, settings, and support surfaces.
Organization Organization plus assigned organization units The org console resolves the signed-in account to an organization profile and then scopes lists, reports, float, and agent actions to assigned units.
Service Provider Platform-wide operations Admin and service-provider roles can review platform-wide entities, with visible route access determined by the mounted admin-console routes and assigned permissions.

Organization Context Resolution

The organization portal does more than check roles. It must also resolve the signed-in account to a live organization context.

  • ORG_ADMIN and equivalent organization-linked users are expected to resolve to an organization and, where relevant, to assigned units.
  • A technically valid account without organization context is redirected to /forbidden?reason=missing-org-context.
  • Unit-scoped pages such as float management use the selected assigned unit as part of the data load, not just the signed-in username.

Agent Hierarchy Rules

Agent hierarchy behavior now appears in both the organization and service-provider guides.

  • SUPER and MASTER are agent tiers, not portal login roles.
  • When an agent record is SUPER or MASTER, the detail pages can expose a child-agent navigation action.
  • Child-agent views aggregate child count, till coverage, shortcodes, and total child float for the selected super agent.
  • Commission analysis must account for superAgentShareRate where a child agent is attached to a super agent.

Service Provider Role Segmentation

  • Full admins and broad service-provider users land on the main admin dashboard.
  • Finance-oriented users can authenticate successfully even when they only need a narrower subset of the admin routes.
  • Current admin-console documentation should be derived from the routes mounted in apps/admin-console/src/App.tsx, not from older support-only route assumptions.

Session and Security Notes

  • /app/security/2fa remains the portal entry point for two-factor setup and status across customer, organization, and service-provider portals.
  • Session and device posture is still enforced centrally by the identity platform rather than by separate per-portal auth state.
  • For troubleshooting, always separate identity failures from portal-context failures. A successful sign-in can still end at /forbidden if the required organization context does not resolve.