SSO Integration with the QS Reputation Manager (MoveIN) ~ Methods & Steps for Implementation

Definition and Supported Methods

Single Sign-On (SSO) enables QS Reputation Manager (MoveIN) back-office users and front-office contact managers or university staff members to employ a singular set of login credentials to access multiple services, such as online portals, forms, and the back-office. To streamline the authentication process, integration with an external authentication system, known as Single Sign-On (SSO) can be enabled. SSO facilitates user authentication via their standard institutional credentials. Thus, with SSO integration activated, users can access the QS Reputation Manager (MoveIN) using a centralized authentication service provided by their university.

To facilitate the smooth implementation of Single Sign-On (SSO) and to provide robust support once your Backoffice is operational with SSO, it is essential for our team to have access to your test IdP metadata login details. To speed up the implementation process your live metadata user credentials are required for testing purposes. We understand how providing access to these credentials may pose security concerns amongst your university IT department, however in their absence, our support engineers cannot test the SSO functionality in front-office, which can increase the time length of a successful implementation. We strongly recommend discussing these requirements with your IT department ahead of time to ensure seamless integration and operation.

When setting up external authentication, you have the option to specify an affiliation, thereby enabling you to further restrict access to specific staff groups. QS Reputation Manager (MoveIN) supports the Shibboleth SSO authentication methods for both (back-office and front-office) areas.

Implementation steps

1. License Verification: SSO is charged additionally with your QS Reputation Manager (MoveIN) subscription. Email your Project Manager or our support team inquiring SSO implementation to check the license type to determine if an implementation fee applies.

2. Complete SSO Preparation Forms: Access the Shibboleth (Federation) form and submit it after filling in your university details to express your will to implement SSO in your institution.
3. Test User Requirement: Discuss the creation of two test user accounts (one for back-office and a second for front-office testing) with your university IT department for implementation purposes. Make sure both test users remain active throughout the implementation phase for ongoing support.
4. Service Provider (SP) Creation: Upon receiving your test IdP metadata, we will create a Service Provider (SP) on our end, and share the SP metadata with you for quick integration in your system.

   SSO card information needed to create SP metadata

   For Shibboleth we require the:
   Name of Federation:
   Production URL of IDP Metadata:
   Test URL of IDP Metadata:

   For ADFS then:
   Test AD Metadata:
   Production AD Metadata:

   
   Test user for both Shibboleth and ADFS:

   back-office email ID and password:
   front-office email ID and password:
   
   

5. SP Metadata Transmission: We will send you the SP metadata link, which needs to be registered on your end in your system.
6. Attribute Testing: Upon confirming that the SP metadata has been successfully registered on your end, we will conduct tests to ensure necessary attributes are passed.

By following the steps outlined above, you can ensure smooth and secure access for both MoveIN back-office users and your fellow Contact Managers staff.