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_SPvs. 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 inCIDAAS_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.
In Trust Desk, each row has:
| UI field | Purpose |
|---|---|
| Field Key | cidaas field (standard or custom from User Setup → Field Setup) |
| External Key | SAML attribute name / URN expected by the SP |
| Data Type | string, integer, or boolean |
| Default | Optional fallback when the attribute is missing |
After creation, open Integrations → Applications → {SAML SP app} → Attribute Mapping to edit the same list. For user identification by a custom field in the wizard, choose custom field and enter the Custom Field Key.
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
For assistance, visit our Support Portal.