SAML SP Integration

cidaas 4.x can act as a SAML 2.0 Identity Provider (IdP) for an external Service Provider (SP) application. Registering the external SP takes just a few minutes in Trustdesk: create an application of type SAML_SP, paste in the SP's metadata, and cidaas handles the rest — issuing signed (and optionally encrypted) SAML assertions once your users authenticate.

SAML_SP vs. SAML login providers This page covers registering an external Service Provider so cidaas acts as its IdP, via Integrations → Applications. It's the opposite direction from SAML IDP Providers under Providers → Identity Providers, where you add an external SAML IdP so your users can log in to cidaas through it — see SAML 2.0 Single Sign-On. Don't confuse the two: this page is about cidaas issuing SAML assertions, not consuming them.

Where to configure

Platform	Location
Trustdesk (cidaas 4.x)	Integrations → Applications → + Create Application → SAML Identity Provider

This app type and creation wizard are Trustdesk-only — there is no legacy Admin Dashboard equivalent.

Prerequisites

Before creating a SAML_SP application, make sure you have:

• Admin access to Trustdesk with app-create permissions (APP_CREATE, APP_MANAGER, or an equivalent role in CIDAAS_ADMINS).
• The external SP's SAML metadata (XML), ready to paste in — up to 256KB.
• Any custom scopes you want to allow, created in advance.

Creating the app

Selecting the SAML Identity Provider template starts a short wizard with five steps.

Step 1: Basic information

Sets the application's identity: client_name, client_display_name, company_name, company_address, and company_website.

Step 2: OAuth settings

This step exists because the app-creation form is shared across all application types — for SAML_SP it's effectively fixed rather than meaningful configuration: grant_types is set to implicit and response_types to token, neither of which drives the actual SAML flow. You can still choose allowed_scopes from your tenant's existing scopes.

Step 3: SAML configuration

The core step. You provide:

• IdP config name (idp_config_name) — an internal label for this configuration.
• SP metadata (sp_meta) — paste the external SP's metadata XML directly into the field (up to 256KB). There's no file upload or fetch-by-URL option; the metadata is parsed from this text.
• NameID format (name_id_format) — the SAML NameID format cidaas should use in assertions.
• Optionally, IdP-initiated login (enable_idp_initiated_login + idp_initiated_sp_redirect_url).
• Optionally, assertion signing (enable_signature + signature_config: which parts to sign, and the algorithm).
• Optionally, assertion encryption (enable_encryption + encryption_config: which parts to encrypt, algorithm, and key transport algorithm).

Known limitation: in rare cases, the signature or encryption configuration can save as empty even when enabled. After saving, open the app's SAML configuration again and verify the signing/encryption settings were applied as expected.

Step 4: Attribute mapping

Map internal user field keys to the SAML attribute URNs the external SP expects, with a data type and optional default value per mapping.

Step 5: Review

A summary step shared with other application types — review your settings before submitting.

After creation

The application's detail page includes a SAML Metadata card where you can review and update the SAML configuration (metadata, signing, encryption, attribute mapping) at any time.

SAML Single Logout

When cidaas acts as the SAML IdP for an external SP (SAML_SP), Single Logout works in both directions:

Direction	Behaviour
IdP-initiated	Logout started in cidaas reaches the external SP's Single Logout callback. Delivery supports HTTP-Redirect binding (as well as HTTP-POST).
SP-initiated	The external SP sends a LogoutRequest with a SessionIndex. cidaas resolves that index to the matching cidaas session, ends the session, and notifies connected OIDC applications through back-channel logout when they have backchannel_logout_uri configured.

Ensure the SP metadata you paste includes the SP's SLO service URL(s). Optional signing of logout messages uses signature_config.sign_targets (LogoutRequests / LogoutResponses). For the complementary flow when cidaas is the SP, see SAML 2.0 Single Sign-On — Single Logout.

What to configure next

Creating the SAML_SP application registers the SP and its SAML behavior. The following are configured separately, after the app exists — they're not part of the creation wizard:

Setting	Field on the app	Configure in	Learn more
User Setup	user_setup_id	User Setup	User Setup
Hosted Pages Layout	hosted_pages_layout_id	Branding → Hosted Pages Layout	Hosted Pages Management
Group selection at login	authentication_setup.group_selection_id	Permission Setup → Group Selection	Group Selection
Verification options / auth setup	authentication_setup (incl. verification_options_id)	SecureOps → Verification Options	See the "Authentication & MFA" row in App management → Configuration sections

The Group Selection pages linked above still describe the legacy Admin Dashboard UI rather than Trustdesk — the underlying concept and field (group_selection_id) are current, but the walkthrough hasn't been updated for Trustdesk yet.

API reference

The SAML-specific fields (sp_meta, signature_config, encryption_config, attribute_mapping, and related settings) are configured through the Trust Desk UI only — there is currently no public v4 API for them. General application fields (client_type, client_name, allowed_scopes, and so on) are covered by the App Configuration API.

Explore related topics

• Application types
• App management
• SAML 2.0 Single Sign-On
• User Setup
• Hosted Pages Management
• Group Selection
• App Configuration API

info

Need Support?

For assistance, visit our Support Portal.