Skip to main content
Auth0 can broker SAML sign-in to Planasonix. You configure a SAML addon (or SAML2 Web App integration) on an Auth0 Application and then paste Auth0’s metadata or endpoints into Planasonix. You need Auth0 Dashboard access (Administrator or a role that can manage applications and rules) and organization admin in Planasonix.
SSO is an Enterprise feature. Sign-in is SP-initiated (start at Planasonix). See SSO.

​
Collect Planasonix SAML endpoints

From Settings → SSO in Planasonix, copy:
  • ACS URL (Assertion Consumer Service / callback URL for SAML responses)
  • Entity ID (audience / SP entity identifier)
You enter these in Auth0 as the application callback and audience.

​
Configure the Auth0 application

1

Create or select an application

In Auth0 Dashboard, go to Applications → Applications. Create a Regular Web Application (or use an existing app dedicated to Planasonix). Disable unused tabs (for example, OIDC-only settings) if you use SAML exclusively for this integration.
2

Enable the SAML2 addon

Open the application → Addons → enable SAML2 Web App. In the SAML configuration JSON or form, set:
  • Callback URL: the Planasonix ACS URL exactly as displayed.
  • Audience: the Planasonix Entity ID exactly as displayed.
Auth0 may label these fields slightly differently in newer UIs; match semantics to ACS URL and Entity ID.
3

Configure SAML bindings and signatures

Use HTTP-POST for the SAML response to the ACS URL unless Planasonix documentation specifies otherwise. Enable signing of assertions as required by your security policy. Download Identity Provider Metadata from Auth0 when Planasonix requests a metadata XML file.
4

Map user attributes

Ensure the SAML assertion includes stable identifiers and profile fields Planasonix expects (see below). Save the addon configuration.

​
Callback URL

The Callback URL in the SAML addon must match the Planasonix ACS URL with no extra path segments or query strings unless Planasonix provides them. Auth0 rejects SAML responses to unregistered callback URLs in many tenants.
If you use custom domains in Auth0, confirm the SSO URL and issuer in the metadata reflect the domain users hit during login. Planasonix must receive metadata that matches the live issuer string.

​
Rules for attribute mapping

Use Auth0 Actions (recommended) or Rules (legacy) to shape user attributes before SAML assertion generation.
Map:
  • email from the primary identity (event.user.email in Actions)
  • given_name / family_name or custom claims for first and last name
Align outgoing claim names with the Attribute mapping table in Planasonix (for example, email, firstName, lastName).
Log a sanitized SAML assertion in a lower environment (or use Auth0’s Try and trace tools) to verify claim names and NameID before you onboard all users.

​
Connection and social logins

If users reach Planasonix through an Auth0 Database, Enterprise, or Social connection, the SAML assertion still originates from Auth0. Ensure email verified requirements and linking behavior match your org’s account strategy so the same person does not get duplicate Planasonix users.
Changing the Auth0 application’s client ID, SAML addon audience, or issuer after go-live breaks SSO until you update Planasonix with matching metadata. Treat those values as production configuration.

​
Finish in Planasonix

Upload Auth0’s IdP metadata or paste SSO URL, issuer, and signing certificate into Planasonix. Test login from the Planasonix sign-in page before you cut over users.

SSO overview

Certificate rotation and org-wide SSO enforcement.

Generic OIDC setup

If your tenant uses OpenID Connect instead of SAML.