RefWorks supports SSO SAML 2.0 protocol integration.
Review this article with IT department. Submit a case to Support team and provide the following details in the request:
- Subscriber name:
What is the Subscriber name? This is how the Institution's name will be displayed in the WAYF (list of Institutions)…. e.g. “University of Washington” or "Central Coast Pharmaceuticals"
- Does institution belong to a Federation? If so, which one (InCommon, OpenAthens, etc.)?
Provide metadata if:
a. Institution does not belong to a federation
b. Institution belongs to a federation to which RefWorks does not belong
RefWorks Federation Details
- If organization does not belong to InCommon Federation or OpenAthens (see #2 above), RefWorks SAML metadata must be downloaded and configured as a service provider.
- What is the IDP (Identity Provider) entityID?
This is the entityID value in institution's SAML metadata. Usually this is in a form of a URL; Example RefWorks' shibboleth: entityID=https://shibboleth.refworks.proquest.com/shibboleth/sp - Is ePPN (eduPersonPrincipalName) or ePTID (eduPersonTargetedID) used to identify users?
Must have at last one ID to configure SSO connection with RefWorks. - Who will be the point of contact at the institution for the implementation?
Include email address for contact.
- Test credentials to debug our configuration and ensure it not working properly.
Test credentials are required before start of implementation.
Note: RefWorks SSO feature (based on SAML 2.0 metadata) can be used in existing services, such as OKTA or Entra ID (formerly Azure Active Directory).
If there is no metadata file, SAML file must be first created and provided to RefWorks.
After form submission, production Service Provider (SP) will be configured to allow Identity Provider (IdP) access to RefWorks. The institution will not be added to the RefWorks login page until testing and other preparations are complete.