How to Test Your SAML Single Sign On

In order to properly test the SAML integration, login credentials for test accounts are required (at minimum, one per user group that is established with SSO). It is recommended that you have test users for each group in your SurveyMonkey Apply site. These test users must be shared with your Customer Engagement Representative to help in testing and troubleshooting. Only applicants should be coming into the SM Apply site via the SSO; co-applicants and recommenders are not supported.

The SAML integration should be configured at least two weeks before the site goes live. Two weeks allows time to sufficiently test and troubleshoot issues. During this time SM Apply requires the SSO technical expert, responsible for implementing the integration on your side, to be on hand to promptly adjust or troubleshoot SSO integration configurations on the IdP as needed.

Upon signing in as a test applicant through the SSO you will want to check in the administrative end of SM Apply to ensure that they were successfully added into Users. You also want to check in Users that all information is being pulled into SM Apply correctly. For example, the name of the user and their email are pulled over and put into the correct fields in SM Apply. If further user attributes have been mapped you will want to check to ensure those attributes have also successfully mapped over upon the user signing on. The Columns option in the user section can be used to add additional applicant custom fields to your users page.

To check the fields have been mapped click Users tab, then filter by Applicants. In the table you will see columns for EmailName, and Last Log In.

When mapping additional attributes to SM Apply, you can add those custom fields to the table as columns as well.

  1. Click on the Columns option in the top right of the toolbar
  2. Click on Custom Fields
  3. Select the fields you wish to add
  4. Click done and the fields will be added as columns to the table   
Manage Users, applicants, more options highlighted with red box showing dropdown to Custom fields highlighted in red box

Once you have successfully signed on with a test user and created/started a submission, sign out of the site and sign back in as that same individual. Check to make sure it brings you back into the correct SM Apply account, with a submission already started. If you log in and the work you had previously done as that applicant is not available you will want to check in the administrative end of SM Apply and verify if there are now two user account profiles for the same test user. If this is the case there is an issue with the UID.

Testing Single-Logout is only required if you have configured it through your IdP.

Single-Logout allows a user to terminate all SSO sessions opened via one log-out, i.e. signing out of SM Apply signs the user out of SM Apply and ends the user's SSO session, making the user sign back into the SSO/be re-authenticated by the IdP on return. When a user chooses to log out of SM Apply, ideally it should also log them out of the IdP, ending the authentication session.

When testing Single-Logout, ensure that the test user is forced to sign back in after signing out through SM Apply. If the user manages to logout of SM Apply but is able to return to the SM Apply site and access their submission without having to re-enter their credentials, Single-Logout has not been correctly configured through the IdP.  

In addition to testing that the sign-in and logout components are working correctly, full tests though complete applications should be conducted using users coming in through the SSO. This includes testing all potential submissions, links, tasks, and resources ensuring everything is working as desired.

If issues are discovered during initial testing of the SSO, please direct your query to the Customer Engagement Representative you are working with. Please provide the following pieces of information to help resolve the issue: the type of user being tested, the login credentials for that user, and the error message (if one is displayed). Screenshots of error messages are encouraged.