Agency Login

Change
or continue with
SSO / Providers

Two-phase login with dynamic identity provider discovery per agency.

Instead of a single static form, login happens in two steps. In the first step only the agency code is collected and sent to the server to retrieve the list of available authentication providers for that reseller. The second step then presents the standard username/password form alongside any discovered SSO provider buttons.

This allows a single landing page to support resellers that use different identity providers — one agency may have Google Workspace, another may have a private Azure AD tenant, and a third may have no SSO at all (password only).

Phase 1 — Provider discovery

GET /reseller/auth/providers/{resellerCode} 
[
  {
    "identifier": "GoogleWorkspace",
    "name": "Google Workspace",
    "icon": "fab fa-google",
    "url": "/reseller/auth/provider/GoogleWorkspace",
    "provider_scope": "global"
  },
  {
    "identifier": "AZURE-001",
    "name": "IRIX Azure",
    "icon": "fab fa-microsoft",
    "url": "/reseller/auth/provider/AZURE-001",
    "provider_scope": "reseller"
  }
]

Provider scope

  • Global — available to all resellers; rendered in grey
  • Agency — configured specifically for this reseller; rendered in blue

If the discovery endpoint returns an empty array or fails (network error, CORS block), the form falls back silently to username/password only — no error is shown to the user.

Phase 2 — Password login

POST /reseller/auth/ application/json 
{
  "resellerCode": "...",
  "username": "...",
  "password": "..."
}

Same contract as the AJAX page — see that page for full response documentation.

Phase 2 — Provider login

Clicking a provider button navigates the browser to BASE_URL + provider.url. The server handles the OAuth / SAML redirect from there; no extra parameters are sent by the landing page.

CORS requirements

Phase 1 (discovery) is a plain GET with no credentials. It still requires an allowed origin — configure each origin explicitly in IRIX Application CORS:

  • http://localhost:<port> — local development server (one entry per port used)
  • https://login.presentation.irix.dcsplus.net — production deployment

If the IRIX CORS configuration supports subdomain wildcards, https://*.irix.dcsplus.net covers all staging and production subdomains in one entry and avoids updating the list for every new environment.

Phase 2 (login) uses credentials: 'include', so the stricter constraints apply — same as the AJAX page:

  • Access-Control-Allow-Origin: <exact-origin>
  • Access-Control-Allow-Credentials: true

Provider redirects are plain browser navigations — no CORS restriction applies there.

References