Integrate SaaS and other vendor software with single sign-on and UW NetID

Who are your users? Do all they all have UW NetIDs? How sensitive is your data? What is your policy for access? These are key questions to answer as you plan your integration—not only for SSO but for enabling and securing access in general.

Contacting us earlier in your project is better. We can review your goals and help you develop your approach to integrating SSO. Generally, we’ll assign an IAM Specialist to assist you with the integration, but you will remain in control of the vendor relationship and related technical configuration.

During the procurement phase of your project, ensure potential vendors know you plan to integrate SSO. Ask them if they support SAML 2.0, OIDC, or OAuth 2.0. If they provide services to large enterprises and/or other customers in the research and education community, they’ll be familiar with SAML 2.0, OIDC, or OAuth 2.0. These are a well-known technical standards for SSO.

Ask your vendor to share information on how they enable customers to integrate SSO. In particular, ask for their technical guide or documentation on using SAML 2.0, OIDC, or OAuth 2.0. The remaining steps assume they support SAML 2.0, OIDC or OAuth 2.0. You can also ask for Azure AD or Shibboleth integration documentation.

If the product supports both, use the guide below to choose between the UW Shibboleth IdP and UW Azure AD to find the best match. We can assist in picking the right solution. Based on the selection the following action steps have different details, so you only need to pick the one for the product chosen. Use “a” for UW Shibboleth IdP and “b” for UW Azure AD.

Our documentation on using SAML 2.0 for SSO describes how to register a service provider with the UW Shibboelth IdP. The vendor’s guide for SSO integration will describe what registration information you need to configure in the UW Identity Provider, and our SAML 2.0 for SSO documentation describes how to use self-service registration to do the configuration.

If your vendor application is pre-integrated, UW-IT will need to do this step. Otherwise, follow our documentation on creating an Azure AD application.

Now follow the vendor’s guide to register the UW Shibboleth IdP with their product. As with the previous step, you can refer the vendor to our documentation on using SAML 2.0 for SSO. It describes how to configure a service to rely on the UW Shibboleth IdP.

This step should only be required if the application is pre-integrated. You may need to share the tenantId or endpoints with the vendor. See Azure AD Application Integration Guide – IT Connect (uw.edu) for more info on that.

Once the service is registered with the UW Shibboleth IdP, you can request the release of appropriate user identifiers and attributes. Follow the vendor’s guide to determine what identifier(s) are required by the product to uniquely identify users. The UW Shibboleth IdP supports several standard identifiers based on UW NetID. If the product also requires other user attributes (e.g. name, email, affiliations, group memberships), you can request them too. As the owner of the business relationship with the vendor, you’ll need to consider what user attributes are required to provide the service and how the released attributes will be protected by the vendor. If you requested an SSO consultation, we can help you obtain the necessary approvals or authorizations needed to release identifiers and user attributes to third-party vendors. Refer to IT Vendor Risk Management (Office of the CISO) and Privacy by Design (UW Privacy Office) for guidance on vendor risk and sharing data with third parties.

Adding attributes for your application to use is sometimes called claims configuration. There are minor differences for Azure AD application claims configuration based on the protocol used. If using SAML, see Azure AD Application Integration Guide – IT Connect (uw.edu). If using OIDC or OAuth, see Azure AD Application Integration Guide – IT Connect (uw.edu).

For more details on claims configuration, see Azure AD Application Integration Guide – IT Connect (uw.edu).

A basic “conditional access” rule can be put in place to restrict access by a group or IP addresses. If you are interested, ask UW-IT via the engagement you opened.

Both SCIM-based provisioning and Conditional Access policies require UW-IT to assist. If you are interested, ask UW-IT via the engagement you opened.

If the application supports SCIM, you can automatically provision users to the vendor application from UW Azure AD. You’ll need to assign any users and groups to the application and setup the SCIM-based provisioning. See Azure AD Application Integration Guide – IT Connect (uw.edu) for more details.

An Azure AD Conditional Access policy can restrict access based on location (IP, GeoRegion, or GPS), group membership, device platform, client application, client device state, sign in risk, and application specific restrictions. This feature is useful for services with complex access policies or a need for higher security restrictions. If you need an Azure AD Conditional Access policy, see Azure AD Application Integration Guide – IT Connect (uw.edu).

Refer to our documentation on using SAML 2.0 for SSO for other topics related testing. Before you finalize your configuration, please verify that email contact information for the service has been provided in the registration of the service. The email contact information is critical to operations; we will notify the registered email contacts about significant changes to the UW Shibboleth Identity Provider.

To validate:

Also take note of when the credential for your application expires. Set a reminder so you renew it before it expires. See Azure AD Application Credentials and Management – IT Connect (uw.edu) for more details about Azure AD application credentials.

Finally, make sure your Azure AD application has at least two owners. If there is a problem with your application, we will know who to contact. Being an owner also provides those users with access to sign in logs to your application, as well as the ability to manage the credential, configuration, user asssignment, and more.

Once your SSO integration is ready for production, we’ll close our consultation (if one was requested). If significant issues or concerns arise during the integration, we’ll summarize them and their impacts so that you and your vendor understand what improvements should be made if the vendor relationship is going to last.