Platform / SSO

Connect your identity provider

Telara authenticates against your existing IdP over SAML 2.0. It does not replace Okta, Entra, or OneLogin — it inherits the organisation you already maintain there.

Admin

SAML 2.0

Before you start

You need admin rights in your IdP to create an application, and admin rights in Telara to add a provider. In Entra this is a non-gallery application — there is no Telara entry in the app gallery, and looking for one is the usual first wrong turn.

Setting it up

Starting screen: Settings → SSO. End state: a test user signs in through your IdP and lands in the right tenant.

Get Telara's service-provider details first

Open Settings → SSO → SP metadata. It gives you the ACS URL, the Entity ID, the NameID format, the binding, and the SAML attributes Telara requires, with the click-path for Okta, Entra, and OneLogin. Your IdP asks for these before it will give you anything back, so collect them before you start on that side.

Create the application in your IdP

Create the SAML app, paste in the ACS URL and Entity ID, and map the attributes. Then download its federation metadata.

Add the provider in Telara

Settings → SSO → Add SAML provider. Two paths: upload the metadata XML you just downloaded, or configure manually with the SSO URL, Entity ID (issuer), and x509 signing certificate. Prefer the upload — hand-entry of a certificate is where most failed setups come from. A single logout URL is optional.

Map the attributes

Email, first name, last name, and display name. If your IdP emits differently named claims, map them here rather than reshaping them at the IdP.

Decide the security settings deliberately

Sign AuthN requests, require signed assertions, and the signature and digest algorithms. Defaults are safe; loosening them to make a first login succeed usually leaves them loose forever. Fix the mismatch instead.

Test with one account before enforcing a domain

Confirm a real sign-in works end to end first.

Three settings worth understanding

Just-in-time provisioning

Creates a user on their first successful login instead of requiring them to be added in advance. It means access is governed entirely by who your IdP lets through, which is usually what you want — and it means a mistake in an IdP group becomes a Telara account without anyone approving it here. Enable it once the group backing this application is one you are confident in.

Domain enforcement

Binds an email domain to this provider, so users on that domain must come through it rather than a password. Turn it on after a successful test sign-in — enforcing a domain against a provider that does not yet work locks out the people who would fix it.

IdP-initiated login

Allows a session to start from the IdP's app tile rather than from Telara. Convenient, and a wider surface: an IdP-initiated assertion arrives unsolicited, with no request from Telara to correlate it against. Leave it off unless someone asks for the tile.

What SSO does and does not decide

SSO answers who is this person. It does not answer what may their agents do — that is policy, scope, and autonomy, which Telara evaluates on every tool call. Connecting an IdP inherits your existing organisational structure as a starting point for those policies; it does not grant or restrict any agent capability on its own. See Autonomy & gates and Scope & access.