The Single Sign On feature is available on our Standard, Premium and Enterprise tiers. To get started, contact your Customer Success Manager, or email@example.com, for information on how to enable single sign on for your account.
SAML Setup for a Mindflash Account
Mindflash is able to integrate with various Identity Providers (IDP) via the SAML authentication approach. Mindflash will take on the role of the Service Provider (SP), which can initiate authenticate requests to the IDP to validate a user in a remote system in order to log them into their Mindflash account. This process is also known as Single Sign On (SSO).
The account owner(s) must have a valid and functional IDP such as OKTA, Salesforce, Microsoft Azure, G Suite (formerly called Google Apps) Feide, etc. Custom IDP’s are acceptable as long as the IDP conforms to the SAML 2.0 standard.
Once all requirements are met, the account owner must contact Mindflash customer support to begin the process of setting up SAML integration. Please have all of the following information available before contacting customer support:
- Service Provider-Initiated Redirect URL: This URL is the location Mindflash will send the initial authorization request. This URL must be able to process SAML Redirect protocol (Http GET). When sending the response form, the generated page should do a POST back to the Assertion Consumer Service (ACS) URL. This URL is sent as part of the authorization request. Note: some higher security systems like Salesforce will require you to enter an ACS URL into the IDP mechanism, which will ignore the ACS URL sent in the authorization request. This is fine as long as the ACS URL is set properly on the IDP side. See more below about the ACS URL setup
- IDP Issuer: This is a string that represents the identity of the IDP, and can be found in the IDP setup.
- IDP Public Certificate: This is the public key corresponding to the private key that the IDP uses to sign the assertion requests. This should be an x.509 certificate that conforms to the SAML 2.0 specification. These certificates are usually self-signed and do not necessarily need to be issued by a certificate authority. This key can be transmitted to Mindflash in various forms (cert, pem, etc). Note: please remember NOT to send your private key, you should not share that with anyone!
- Service Provider Issuer: This is a string that corresponds to the identity of the Mindflash Service Provider. This value defaults to “mindflash.com”, but can be overridden if necessary depending on the specific requirements for the IDP. The IDP administrators will need to enter this in the IDP setup.
- Login Button Text: (Optional) This is the text that will display on the login button on the Mindflash Login Screen. The default text is “Login with company credentials”, but may be set according to your own wishes.
- Login Button Graphic: (Optional) As an alternative to the login button text, you may supply your own login button graphic to be displayed on the Mindflash login screen. This graphic must be 201x86 pixels, where the upper 201x43 pixels is the normal button state, and the lower 201x43 pixels is the mouse-over button state.
Assertion Consumer URL
The ACS URL usually takes on the form "https://sso.mindflash.com/saml/acs". This ACS URL requires that the IDP sends along the RelayState variable that is passed to it with the authentication request to the IDP. This also implies that IDP-Initiated login requests must send the Mindflash Account ID as the RelayState variable when attempting to log a user into Mindflash.
An alternative to this is simply using the Mindflash portal subdomain name in the ACS URL. An example ACS URL would be "https://acme.mindflash.com/saml/acs". In this case, “acme” is the company portal subdomain name. The RelayState is not required in this instance.
Please specify which solution you prefer during your conversation with Mindflash Customer Service.
Mindflash User Authentication
In order to log a Mindflash user in, the IDP must send the appropriate Subject ID to Mindflash as part of the authentication response. This is how Mindflash will know which user to log in. Mindflash supports 4 different identification methods:
- User ID: This is the internal Mindflash User ID of the user to log in. In order to support this, the IDP-side must have associated their user records with these Mindflash internal ID’s. This is frequently done via the Mindflash public API.
- Email: This is the email address of the associated user in Mindflash. In order for this method to work, all user emails must be in sync with their corresponding mindflash records. If the email is not found in the Mindflash portal, login will fail.
- Username: This is the Mindflash username of the user to log in. The IDP-side must have the Mindflash username. This is useful if all Mindflash users are given the same usernames as the remote IDP system records. Again, this is frequently done via the Mindflash public API.
- Federated ID: This can be a remotely specified user ID. In order for this to work, the Mindflash user records must have the federated ID entered. (Currently there is no way to associated a federated ID with a Mindflash user. This is a feature that will be implemented in the future).
In order for the authentication to be successful, the IDP must send one of these ID’s along in the Subject field of the authentication response. In addition, Mindflash must have a record of this ID in some form attached to the user’s record.
Single Sign On with Provisioning
Mindflash can automatically add users to your Mindflash account the first time they successfully sign in. First, you will need to let your Customer Success Manager know you want this turned on for your account. Second, please provide the following attributes in your SAML response:
Once all information is shared with Mindflash, and all required information is entered on the IDP-side, we can begin the SAML integration. It will be very useful to have someone test the integration quickly so we can troubleshoot any problems as they arise.