Single Sign-On (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. In the context of SurveyMonkey Apply, SSO implementation allows clients to leverage their existing user authentication framework to permit and provision access to an SM Apply site. By the end of this document, you will know how to set up such an integration using SAML protocol.
There are 4 key entities to an SSO integration:
The user is an applicant who is trying to login and access SM Apply.
To improve the user experience of external users who may be invited to your site (co-applicants, recommenders), your SAML integration will not be utilized. Doing so will help prevent unforeseen challenges such as your users not being invited with an email address matching your IdP's records.
The Identity Provider is an instance of an SSO issuing server that is responsible for housing and validating a user’s account credentials as well as provisioning access. It has a few main purposes:
The Service Provider is the software or system, in this case SM Apply, establishing a trust relationship with an IdP and requesting user account provisioning from that IdP. It is also responsible for consuming information (attributes/metadata) that may be passed from the IdP.
The protocol is what facilitates the integration between the IdP and SP. It defines the handshake (sequence of events/data passing) for the integration.
What SSO provider will you be using? [SAML, NetForum, CAS, or OAuth]
Which user groups need to sign in via SSO? [Applicants]
How are users uniquely identified? [i.e. email, student number, employee ID, etc.]
How will users enter Apply? [SP-initiated SSO or IdP-initiated SSO]
What attributes need to be passed to Apply? [First name, Last name, email, etc.]
SAML: Can your IdP automatically consume Apply’s XML metadata?
SSO works by creating an integration between an IdP and Apply via the SSO protocol. The handshake passes along key user information, including the UID. The key role of the IdP is to verify that a user’s information is known and that correct account details have been provided. Once Apply has received the verification, the user is then able to access Apply. A new Apply account will be created for a user if one does not already exist. If an account already exists for this user, Apply will match the incoming user to the pre-existing account using the email address received from the IdP.
SSO can be initiated in two ways: SP-initiated and/or IdP-initiated.
SAML: Do my assertions and responses need to be signed?
To successfully log users in with SAML, SMA requires that all instances are sending signed assertions and responses from your organization’s SSO portal into Apply. This configuration must be done within your own settings and is not something our Support or Engineering teams are able to modify on your behalf.
“Service provider initiated” SSO is when a user comes first to the SM Apply site, clicks the SSO sign-in button and inputs their username and password. This then starts the authentication process with SM Apply sending out a call for authentication to the IdP.
“Identity provider initiated” SSO begins when a user signs into your main hub, not SM Apply. The user clicks an option on the company’s page that brings them into Apply. In this case the IdP is initiating the sign-on to SM Apply.
Due to the technical nature of implementing an SSO Integration, and the number of authentication services, SM Apply recommends there to be a technical expert experienced with SAML to be facilitating the configuration aspects on the client end.