Setting up Single Sign On (SSO) for new E-resources

Setting up Single Sign On (SSO) for new E-resources

Summary: Setting up SSO access for new e-resources 


Some e-resource databases do not have an option to be accessed via MSU EZProxy, and can only use SSO (single sign on) method. The different between accessing e-resources via EZProxy vs. SSO:

Preliminary information

When requesting a new SSO service, you will need to gather preliminary information beforehand for the request form

  1. Obtain necessary information from the vendor. Typical vendor's information needed to fill out the MSU SSO request form:

    1. Application/database name

    2. The library contact person who is responsible for submitting the request (usually Ranti Junus, Systems Librarian for E-resources) 

    3. Vendor's EntityID

    4. Vendor's Assertion Consumer Service (ACS) URL

    5. Data from the MSU system that the vendor needs to login to their system. This is called "Identity Attributes" (usually name and email address, or MSU username and email address)

    6. Information about vendor's data security and user privacy. This can be the URL(s) or website of the vendor that address these two topics. 

Submit the SSO request 

  1. Access the request form

    1. MSU Unified Login Services 

    2. Click the green "Request MSU Unified Login Services" bar at the right side of the page and login with MSU NetID. The system should recognize the department of the requestor and will automatically populate the form.


  2. Fill out the initial information. 

    1. Choose SAML2 for the Centralized Authentication option underneath the Department line. Additional set of questions will be shown.


       


    2. Fill out the details (refer to the screenshot above)

      1. Application Owner

      2. Business Functional Owner

      3. Service or Application Description

      4. New SSO Setup: New

      5. Hosting Type: Cloud 


    3. Fill out the Application Information (information about the SSO use)

      1. Access Groups: All MSU Users

      2. Confidential Data in Application: None of the Above

      3. Application Audience: Staff, Faculty, Students

      4. Audience Size: depends, but 1,000-10,000 usually would be sufficient. 

      5. Application Critically: Partial disruption of one or more auxiliary functions

      6. Confidential Data Purpose: depends on the application. Typically, we don't use any of confidential data. Explanation about this can be gathered from the vendor's website re. data
        privacy








    4. Fill out the rest of the Application Information (information about vendor' SSO system. Refer to the preliminary information that you gathered from the vendor)

      1. Identity Attributes Required: this depends on the vendor. Usually, the data needed by the vendor is "First Name", "Last Name", and "Email". This information should be sufficient to reduce unnecessary data sharing with the vendor. 

      2. Identity Attributes Use: explains how users will use the database. For example, "Email address will be used to create a user account on the vendor database to allow users to save their search results and collect articles they need for their project." 

      3. Controls for MSU IDP Compliance: explain how vendor will use and protect the user data. Refer to vendor's website. You can quote and/or include the URL of vendor's privacy statement.

      4. Application Username: depends on the vendor's need. "Email" is the typical username. 

      5. Sign Responses: "Yes" (default)

      6. Sign Assertions: "No" (default)

      7. Encrypt Assertions: "No" (default)

      8. PROD EntityID: fill out vendor's EntityID information (refer to the preliminary information that you gathered from the vendor) 

        • You can safely ignore the QA, TEST, and DEV EntityID, unless if the vendor requires us to use their test server first. 

      9. PROD ACS URL: fill our vendor's ACS URL (refer to the preliminary information that you gathered from the vendor)

        • You can safely ignore the QA, TEST, and DEV EntityID, unless if the vendor requires us to use their test server first.











    5. Click the Submit button. A new ticket will be created, and you will receive email notification of a new ticket request.



Next steps

Someone from the MSU Identity Management team will review the request and may request additional information, if needed. If the submitted information is complete, they will forward the ticket to MSU Registrar's Office (regarding student data privacy). The process of setting up the initial SSO system can take 1 day to 1 week, or more, depending on the complexity of the vendor's system. Typically, we receive the response from the MSU Identity Management team within 3 days informing us that the SSO system is ready to be deployed.  

  1. Receive the MSU SSO metadata from the MSU Identity Management

  2. Send the information back to the vendor

  3. Receive the URL of the database from the vendor that we can test for SSO access 

  4. Test and verify that login via SSO works, do search, or browse, read the content, and test any database features they might have (share link, save searches, etc.) 

  5. Communicate and work together with the subject specialist in testing the database.

  6. Discuss with the vendor on any unexpected outcome when testing the database (missing images, error messages, etc.) and work with them until they fix the problem.

Deploy the database to the public

Once everything works, we can add the database to the A-Z Database list. 









Policies

Contact

Ranti Junus

Team

ERM

Updated

03/2025

Created

01/2025