Skip to main content
MindTouch Success Center

SAML SSO - Supported scenarios

SAML single sign-on (SSO) and single logout (SLO) scenarios supported by MindTouch.

Single Sign-On management moved from the Control Panel to the Integrations section of the Dashboard in Release 2019-03-21. ​​​​​Single Sign-On configuration is now managed through the MindTouch Support Team and viewable on Dashboard > Integrations > Single Sign-On Configuration.

SAML 2.0 single sign-on (SSO) scenarios

MindTouch supports SAML 2.0 SSO with HTTP redirect-POST binding:

  • Authentication requests from the service provider (SP) to the identity provider (IdP) are sent as an HTTP redirect.
  • Responses or requests from the IdP to the SP are expected to be sent as HTTP Post.

SP-initiated SSO

SP-initiated SSO is a scenario in which the user initiates the sign in process in the application (e.g., the MindTouch service provider) either actively or passively and is authenticated by the IdP.

  • Active SSO: User signs into the MindTouch service provider by clicking the Sign In link
  • Passive SSO: User visits a private page or file attachment they cannot access without authentication
  • IdP authentication: Both active and passive SSO send users to the IdP for authentication

IdP-initiated SSO

IdP-initiated SSO is a scenario in which the user is using an internal application such as Salesforce and has already authenticated with the IdP. Users click on a link to the MindTouch service provider to begin an SSO session. If needed, the MindTouch service provider automatically provisions the user in the MindTouch site (or the existing user is found), and the user is signed in.

User profile information in IdP responses 

During the authentication process, the MindTouch service provider attempts to extract the following information from assertions:

Username (required)

The MindTouch service provider looks for the username value in the following assertion XML node:


Allowed NameID formats are:

  • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent  (Preferred to ensure the identity between the MindTouch service provider and the IdP since it never changes)
  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (Required for PingOne to authenticate with a username/password combination)
  • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Display name (optional)

If set, the display name is shown in the MindTouch site instead of the username. The display name is often a friendlier version of a username, such as "Bob Jones" instead of "rjones." The MindTouch service provider will attempt to build a display name from the assertion with attributes found in the following assertion XML nodes:


The MindTouch service provider will first attempt to use the display name attribute value from one of the following response XML nodes:

  • DisplayName

If no display name is found, concatenate the first and last name attribute values from the following assertion XML nodes:

  • FirstName
  • LastName

The MindTouch service provider can also use a find-and-replace pattern to build a display name from any attributes in the assertion XML. MindTouch Professional Services can configure a pattern for your MindTouch service provider to use when parsing the assertion XML for attributes you would like included in the display name.

Email address (optional)

If set, the user email is associated with the user account is set to the value of the attribute. In general, an email should be provided to allow subscriptions to notifications. The MindTouch service provider will attempt to find the email address in one of the following IdP sign-on response XML nodes:


  •  EmailAddress

Groups (optional)

If set, the user's group membership will be synchronized with the value of the attribute. If a user is a member of any groups not listed in the attribute value, the user will be removed from those groups. The attribute name is configurable, and can be set to any incoming attribute name. The attribute value can be provided in two different formats: a single XML text node, or multiple XML text nodes:

<!-- multiple XML text node example -->
  <Attribute Name="group">

<!-- single XML text node example (the delimiter character between group names is configurable) -->
  <Attribute Name="group">
    <AttributeValue>foo, bar, baz</AttributeValue>

Other metadata

Other attributes may be included in the assertion, which are stored as a property on the MindTouch site user. These attributes are stored as a JSON string and can be accessed programmatically using DekiScript. The attributes are found in the following assertion nodes: 


// fetch the SAML assertion attributes as JSON text
let json =["mindtouch.saml#attributes"].text; 

SAML 2.0 single logout (SLO) scenarios

In addition to SSO, MindTouch supports SAML 2.0 single logout (SLO) with HTTP redirect-redirect bindingSLO allows a MindTouch site user to click the Sign Out button on a MindTouch site, which signs the user out of both the MindTouch site and the IdP.

While SLO is optional, it is highly recommended for private MindTouch sites. Without SLO, signing out of a MindTouch site redirects the user to the SAML SSO identity provider, which maintains the SSO session. In effect, it creates a scenario where the user cannot sign out without signing out of the SAML SSO identity provider first, creating a confusing experience.

User-initiated logout (MindTouch): The user actively clicks the sign out link on a MindTouch site. The user is signed out of the MindTouch site.

User-initiated logout (other application): If the IdP and all SPs in the federated SSO session are configured correctly and the user signs out of any other application in the federated SSO session, the MindTouch service provider receives a sign out request from the IdP and signs the user out of the MindTouch site.

SAML SSO security 

HTTP communication security

HTTP communication security is ensured by the transport layer security (TLS) protocol between the IdP and SP.

Message signing and encryption

Messages can be signed and encrypted to ensure message-level security.

  • The MindTouch service provider requires that all assertions from the IdP are signed. Signing the assertion allows the MindTouch service provider to verify that the assertion originated at the trusted IdP by validating the assertion's signature against the trusted IdP's public X.509 certificate.
  • Optionally configuring the MindTouch service provider with a public X.509 certificate and private key allows the MindTouch service provider to sign outgoing requests to the IdP, as well as decrypt assertions from the IdP.

To take advantage of these security features, the IdP must be configured to validate signatures and encrypt assertions using the same private key and public X.509 certificate that the MindTouch service provider uses to sign outgoing requests to the IdP.

  • The MindTouch service provider signs outgoing messages to the IdP with the secure hash algorithm SHA-1.
  • The MindTouch service provider supports incoming messages from the IdP signed with the SHA-1 or SHA-256 hash algorithms.

Assertion decryption

The MindTouch service provider can decrypt assertions from the IdP encrypted with AES-128, AES-256 or Triple DES encryption algorithms.

Password security

User passwords are never transmitted as part of a SAML SSO authentication request or response. A signed authentication request indicates a new user should be created. This request only contains the username and any additional metadata (name, email address, etc.) that was configured by the IdP administrator.


  • Was this article helpful?