Riskline Portal SSO

Setup and provisioning

SSO for a company is configured by Riskline administrators as part of company onboarding. Before users can sign in via SSO, the following must be in place:

  • SSO must be enabled for the company in Riskline configuration.
  • The identity provider (Microsoft Entra ID, Google, or both) must be selected for that company.
  • One or more email domains must be registered for the company. Only users whose email address matches a registered domain will be granted access and associated with the correct company.

Clients should raise these requirements with their Riskline account contact during onboarding

Standards and terminology

  • OAuth 2.0 (IETF) is used for authorisation; OpenID Connect builds on OAuth 2.0 for identity (sign-in). Commercial products often refer to this together as "OIDC / OAuth 2.0 SSO."
  • SAML 2.0 is a different browser-SSO stack. Riskline does not implement a SAML service provider (SP) today, so customers cannot complete SSO by configuring only a SAML app in their IdP unless they use a supported OAuth/OIDC path (see Okta and other IdPs).

Supported identity providers

Microsoft Entra ID

Users sign in with their organisational Microsoft accounts according to your Entra policies (including MFA and Conditional Access, when configured in Entra).

Google

Riskline can use Google as an identity provider for Google Workspace accounts. MFA and organisational policies are enforced by Google Admin as applicable.

Okta and other enterprise identity providers

Okta is not a separate, first-class "click Okta" integration in the product today.

Enterprises that standardise on Okta often still use Microsoft Entra ID as the system of record for Microsoft workloads, or they federate identities so users sign in through Entra. Where Entra is the IdP presented to Riskline, the documented Entra ID path applies.

If a customer requires direct integration only with Okta (or Ping, OneLogin, etc.) without Google or Entra:

  • That typically implies SAML 2.0 and/or OIDC with that vendor's authorisation server as a dedicated integration. SAML is not available in Riskline today; additional OIDC work would be a product roadmap discussion.
  • Procurement and security teams should align on which IdP will issue tokens to Riskline (Entra vs Google vs future options).

End-user experience

  • The user opens Riskline and selects their company context.
  • The user chooses Sign in with Google or Sign in with Microsoft, depending on which provider(s) have been enabled for their company.
  • The browser opens the identity provider's sign-in experience (OAuth/OIDC).
  • After successful authentication at the IdP, Riskline verifies that the user's email domain matches a domain registered for the company, then completes the flow server-side and establishes an application session.

Multi-tenant behaviour

  • Each company in Riskline has its SSO provider(s) and allowed email domains configured by Riskline administrators.
  • A user's email domain must match a domain registered for the company. This is both the access control gate and the mechanism by which users are associated with the correct company tenant.
  • A company may have one or both providers enabled (Entra ID and/or Google), depending on requirements.