T
Telblu

Access & identity

Single Sign-On (SSO)

Telblu supports production-ready SAML 2.0 Single Sign-On end-to-end. Administrators configure the identity provider metadata URL, email domains and organisation-level SSO policies. End users sign in with their work email - Telblu resolves the matching identity provider by domain, initiates the SAML redirect, processes the callback and establishes an organisation-scoped session with roles loaded and Row-Level Security enforced.

How it works: Email-first sign-in resolves the authentication method for the user's domain, automatically redirects SAML-enabled organisations to their identity provider, and validates the returning SAML session against organisation membership, existing role assignments and the organisation's Require SSO policy before granting access. Every SSO event is written to the audit log. Automated SCIM provisioning and generic OIDC federation are not implemented today; roles remain administrator-assigned per organisation.

Authentication architecture

Telblu delegates credential verification to a trusted identity provider using standard SAML 2.0 or OpenID Connect protocols, removing the need for users to maintain a separate Telblu password.

Identity federation

Federation lets an organisation's existing user directory govern access to Telblu. Joiner, mover and leaver changes made in the corporate directory are reflected at the next sign-in.

Enterprise access

SSO is configured per organisation. Administrators can enforce SSO-only sign-in, route specific email domains to an identity provider and control which authentication methods are available.

Centralised authentication

Policy is managed in one place. Password complexity, MFA requirements, session lifetime and access revocation all flow from the identity provider or Telblu's authentication policy.

What is Single Sign-On?

Single Sign-On is an authentication scheme that allows a user to log in to multiple independent applications with one set of corporate credentials. In Telblu, SSO is implemented through standard federation protocols - SAML 2.0 and OpenID Connect - so the platform never sees or stores the user's corporate password.

Why enterprises use it

Enterprises use SSO to consolidate authentication control. Instead of enforcing password policy across dozens of SaaS applications, IT teams manage one identity store and one set of access policies. Onboarding, offboarding and access reviews become centralised operations.

Reducing password fatigue

Users no longer need to remember a unique Telblu password. They sign in with the same credentials they use for email and other corporate systems, which reduces help-desk tickets and weak-password reuse across services.

Benefits for IT administration

SSO gives administrators a single point of control for authentication policy. Multi-factor authentication, conditional access, session lifetime and account status are governed by the identity provider and honoured by Telblu during every sign-in.

Relationship to RBAC

SSO answers the question "Who is this user?" by proving identity. Role-Based Access Control answers the question "What can this user do?" by applying scoped role assignments. The two systems work together but remain independent.

Authentication and authorisation are separate

Info
Single Sign-On authenticates a user's identity. Roles & Permissions determine what that authenticated user can access within Telblu.

SSO authentication flow

The flow below describes a SAML 2.0 or OIDC sign-in. Telblu initiates the request, the identity provider performs authentication, and Telblu consumes the returned assertion to create a platform session.

1. User requests access

The user navigates to Telblu and enters their corporate email address. Telblu resolves the email domain to the organisation's configured identity provider.

2. Redirect to identity provider

The browser is redirected to the SAML or OIDC identity provider with a signed authentication request. The request includes the organisation's entity ID and a secure relay state.

3. Identity provider authenticates

The identity provider validates the user's corporate credentials and any required second factor, then issues a signed assertion or ID token back to Telblu.

4. Assertion validation

Telblu validates the assertion signature, issuer, audience, expiry and recipient. Claims such as email, name and group membership are normalised into a canonical identity record.

5. Session created

Once validated, Telblu creates a secure platform session. The user is routed to the workspaces and departments permitted by their role assignments.

Authentication flow

The diagram below shows the complete path from a user attempting to access Telblu through to platform access being granted. Each stage represents a distinct security or identity decision point, with authentication and authorisation responsibilities clearly separated.

Stage 1

User

The workforce user initiates access from a browser, mobile app or API client.

Stage 2

Enterprise Identity Provider

The corporate identity provider receives the authentication request and challenges the user.

Stage 3

Identity Verification

The user proves their identity through credentials, MFA, device trust or conditional access checks.

Stage 4

Successful Authentication

The identity provider issues a signed assertion or token confirming the user's identity.

Stage 5

Telblu User Account

Telblu locates or provisions a local identity record linked to the external subject identifier.

Stage 6

Organisation

The user account is matched to the organisation that owns the authenticated email domain.

Stage 7

Role Resolution

Role assignments are evaluated for the user within the organisation and department scope.

Stage 8

Permissions Loaded

The effective permission set is computed from resolved roles and applied to the session.

Stage 9

Platform Access

The user is granted access to workspaces, data and actions permitted by their permissions.

User

Every flow begins with a user requesting access. The user may arrive at Telblu directly, through a deep link, or via an enterprise application launcher. The device, browser and network context are recorded for risk evaluation.

SAML 2.0 Identity Provider

Once the runtime SAML flow ships, Telblu will delegate authentication to the SAML 2.0 identity provider configured for the organisation in the Administration → SSO screen. The identity provider owns the user directory and authentication policy.

Identity Verification

The identity provider verifies the user according to corporate policy. This may include a primary credential, a second factor, device compliance, location risk and biographical challenge questions.

Successful Authentication

Once verified, the provider issues a cryptographically signed assertion or ID token. This artifact is time-bound, audience-restricted and contains claims that Telblu uses for identity matching.

Telblu User Account

Telblu consumes the assertion and resolves it to a user account. If no account exists, just-in-time provisioning can create one using the claims supplied by the provider, linked by a stable external subject identifier.

Organisation

The authenticated user is associated with an organisation. This determines tenant isolation, the set of identity providers, policies and administrators that govern the account.

Role Resolution

Telblu evaluates role assignments for the user at the organisation and department levels. Provider-supplied group claims may be mapped to roles, but the final role set is controlled inside Telblu.

Permissions Loaded

Resolved roles are translated into an effective permission set. This set is cached in the session and re-evaluated when roles change, sessions refresh or administrative actions alter the user's access profile.

Platform Access

With identity proven and permissions computed, the user is admitted to the platform. Every subsequent request carries the session token, which Telblu validates against the loaded permission set and current account status.

Authentication proves identity; authorisation grants access

Info
The first four stages prove who the user is. The remaining stages determine what the user can do. SSO is responsible for the identity proof; Telblu RBAC is responsible for the access decision.

Identity federation

Federation is the trust relationship between Telblu and an external identity provider. It allows authentication decisions made outside Telblu to be accepted inside Telblu, provided they are cryptographically verifiable and conform to the configured policy.

Trust establishment

Telblu and the identity provider exchange metadata: entity ID, SSO URL, certificate and attribute mappings. This establishes the cryptographic trust that underpins every subsequent sign-in.

Attribute mapping

Standard claims such as email, given name, family name and group identifiers are mapped to Telblu user fields. Custom attributes can be used to drive role or department assignment during provisioning.

Just-in-time provisioning

When a federated user signs in for the first time, Telblu can create a local identity record automatically. The record is linked to the external subject identifier for future matching.

Enterprise access management

SSO is more than a convenience feature. It is the primary control surface for how workforce identity governs access to Telblu at the organisation level.

SSO enforcement

Administrators can require SSO for an entire organisation. When enforcement is enabled, password and social sign-in are disabled for users whose email domain matches the configured provider.

Domain routing

Multiple identity providers can be configured for different email domains within the same tenant. Each domain is routed to the correct provider without the user selecting it manually.

Deprovisioning

Disabling or deleting a user in the corporate directory terminates their ability to sign in to Telblu. Existing sessions are invalidated at the next validation checkpoint.

SSO and Role-Based Access Control

A successful SSO sign-in establishes identity, but it does not automatically grant platform access. Telblu applies Role-Based Access Control after authentication: the user's identity is matched to role assignments, and the effective permission set is computed against organisational scope.

ConcernSSO responsibilityRBAC responsibility
Identity proofVerifies the user is who they claim to beReceives the verified identity record
Access decisionsMay supply group or department claimsMaps roles and scopes to data access
RevocationPrevents future sign-ins when disabledRemoves or suspends role assignments
Audit evidenceProvides assertion and provider detailsRecords role evaluation and access events

Security considerations

SSO shifts credential verification to an external identity provider, but Telblu retains responsibility for validating the result, protecting the resulting session and enforcing authorisation boundaries. The following controls apply to every deployment.

Identity verification

Info
Telblu relies on the configured enterprise identity provider to verify the user's identity. The platform validates that the returned assertion or token is issued by a trusted provider, is within its validity window and is intended for the correct tenant and service endpoint. Identity proof is accepted only when all validation checks pass.

Secure session handling

Best practice
After authentication, Telblu issues short-lived session tokens and rotating refresh tokens. Sessions are bound to device context and invalidated on logout, timeout or administrative revocation. Tokens are never exposed to untrusted code.

Role validation

Info
SSO supplies identity claims; Telblu resolves those claims into user accounts, organisations and role assignments. Role resolution is performed after authentication and is independent of the identity provider's group claims.

Permission enforcement

Warning
Permissions are enforced at the application and data layers. A valid session alone does not grant access to workspaces, records or administrative actions. Every request is evaluated against the resolved permission set and current account status.

Audit logging of authentication events

Info
Authentication events - including sign-in success and failure, token refresh, session revocation and role resolution outcomes - are written to the audit log. These events support security monitoring, incident response and access reviews.

Relationship to other features

SSO is one component of Telblu's access and governance model. The diagram below shows how authentication, authorisation, administration and monitoring features connect to deliver a complete enterprise identity solution.

Authentication

Proves user identity through credentials, MFA and identity provider integration.

Single Sign-On

Delegates credential verification to the enterprise identity provider.

Roles & Permissions

Maps the authenticated identity to role assignments and permission scopes.

Administration

Configures identity providers, policies, user lifecycle and tenant settings.

Security

Defines protection controls, monitoring rules and incident response workflows.

Audit Logs

Records authentication events, access decisions and administrative changes.

Authentication drives SSO

The authentication service decides whether to challenge the user locally or redirect to an enterprise identity provider. SSO is an authentication method, not a separate access layer.

SSO feeds role resolution

A successful SSO sign-in produces a trusted identity record. Roles & Permissions uses that record to determine the user's effective access within the organisation.

Administration controls configuration

Administrators define which identity providers are trusted, which domains are routed to SSO and which authentication policies apply to each user population.

Security and audit close the loop

Security policies set the protection bar for sessions and credentials. Audit Logs capture the evidence needed to verify that those policies are being enforced.

Deployment notes

Authentication behaviour in Telblu is governed by tenant configuration. The exact methods, identity providers and integration protocols available to your organisation depend on how Telblu is deployed and licensed.

Deployment-dependent integrations

Info
The authentication architecture has been designed to integrate with enterprise identity solutions. Available authentication methods and integrations depend on your Telblu deployment and configuration.