Single sign-on (SSO) simplifies the delivery of secure, usable, accessible IT services by making user authentication easier for customers to implement and for individuals to use on an everyday basis.
This page describes integration options for SSO with UW NetID using the UW Identity Provider (IdP). The information is applicable to any application or IT service that uses the web for user authentication. Authenticate your users describes options for other platforms.
Need help with SSO? Getting started with an SSO integration or want to brainstorm different approaches to integration? We regularly assist customers with their SSO integrations. Review the resources below, and contact us if you need help.
Follow these guides to integrate directly with the UW Identity Provider
You can integrate your services directly with the UW IdP using a Security Assertion Markup Language (SAML) or OpenID Connect (OIDC)(*). The following guides provide details for customers in different situations:
- Integrate SaaS and other vendor software
Learn how to approach SSO integration with software-as-a-service (SaaS) and other vendor products. We provide guidance for direct integration using SAML 2.0.
- Use Shibboleth SP software for SSO
Learn how to use Shibboleth Service Provider (SP) software to enable SSO for applications hosted on Apache or Microsoft IIS web servers. Shibboleth SP software supports SAML 2.0, federations, and use of multiple identity providers at the same time, including social login through the UW Social-to-SAML gateway. It is also used for user authentication on the UW Home Page Servers and UW Shared Web Hosting, and is a software option on UW-IT Standard Managed Servers.
- Use SAML 2.0 for SSO
Learn how to configure SAML 2.0 software to rely on the UW IdP for SSO. This general guide applies to SAML 2.0 code libraries, as well as cloud-based identity solutions such as Amazon Cognito, Auth0, etc.
- Use OIDC 1.0 for SSO (*)
Learn how to configure OIDC software to rely on the UW IdP for SSO.
- Configure SSO for the AWS Management Console
Configure SSO to sign in with UW NetID to the Amazon Web Services (AWS) Management Console.
- Integrate applications built for cloud native architectures (**)
Share and learn how your container-based applications, “serverless” applications, and other emerging cloud-native architectures can integrate SSO.
- Authenticate users of native mobile applications (**)
Are you building or deploying a native mobile application, such as an iOS or Android application? Want to adopt best current practices for integrating native mobile applications with user authentication and secure access to APIs? Contact us to discuss strategies for authenticating users of native mobile applications.
Other SSO integration options
Customers can also integrate SSO through other IT services:
- UW Azure Active Directory
UW Azure Active Directory (AAD) supports SSO with UW NetID for Microsoft sign-in to applications and IT services that integrate with AAD.
- UW Google for Education
UW Google supports SSO with UW NetID for Google sign-in to its core apps (Gmail, Drive, Sites, Groups, Calendar), Google Cloud Platform (GCP), as well as additional apps that rely on Google sign-in.
- Canvas Learning Management System
Canvas supports SSO integrations for applications using LTI (Learning Tools Interoperability) protocols, managed through the UW Learning Management System Vendor Integration Program.
- Other cyberinfrastructure
Cyberinfrastructure such as CILogon, ORCID, and Globus provide additional ways to integrate SSO with UW NetID.
Frequently asked questions
What is the UW Identity Provider?
The UW Identity Provider (idp.u.washington.edu) is the central hub for SSO integrations, where users can safely enter their UW NetID credentials for verification, and where policies for SSO are enforced. It’s called an “identity provider” because it provides identity services to individuals and authorized applications and other IT services that rely on it. UW-IT uses Shibboleth Identity Provider software to operate the UW IdP. Shibboleth IdP software not only enables SSO, but also supports the Internet and community standards required for the UW to participate in research and education “federations” like InCommon and eduGAIN.
What are the benefits of integrating SSO with UW NetID?
SSO reduces burden on users while enabling you to implement your policies for user authentication.
- Customers can focus on service delivery
SSO allows you to deliver your applications and IT services without having to manage accounts, passwords, and 2FA devices.
- Users don’t have to create an account
SSO enables users to sign in with their UW NetID—the same account they use for other services at the UW—rather than having to create more accounts.
- Users don’t have to sign in as often
If a user signs in to one service integrated with SSO, such as MyUW, Canvas, or Workday, they won’t have to sign in again during the same session to access other services, like yours, that also integrate with SSO.
What features do customers get from integrating SSO with the UW IdP?
If you integrate directly with the UW Identity Provider, you can rely on the following features:
- Standards compliance
The UW Identity Provider supports open interoperable industry and community standards for SSO, like Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) (*), and eduPerson, as well as trust and identity infrastructure used in the research and education community like InCommon and eduGAIN.
- Default 12-hour session
By default, users get a 12-hour SSO session upon successful authentication with the UW Identity Provider. Each session is tied to an individual browser session, and users can have sessions on multiple devices at the same time. The session ends after 12 hours or when a user quits their browser. The duration aligns with best current practices established by the National Institute of Standards and Technology.
- User attributes
The UW Identity Provider can release a variety of user attributes, including identifiers such as UW NetID, names, affiliations, and group memberships. Attributes are released using standard SAML and OIDC mechanisms (*). Attributes can be useful for access control decisions and personalization. Standard attribute release policies apply, including authorization prior to release of attributes to 3rd parties.
Requests to force reauthentication are supported for services that integrate directly with the UW Identity Provider. Reauthentication can reduce the risk of unauthorized access when a user leaves a browser session open on an unattended and unlocked computer. Reauthentication can be requested through standard SAML or OIDC mechanisms (*). However, excess reauthentication can annoy users, so use it judiciously.
- Two-factor authentication (2FA)
Requests for two-factor authentication are supported for services that integrate directly with the UW Identity Provider. 2FA can be requested through standard SAML or OIDC mechanisms (*); or it can be enforced by the UW Identity Provider itself, by configuring “auto 2FA” or “conditional 2FA” when you register your service.
- Access controls
Customers who integrate directly with the UW Identity Provider can request access controls (authorization) that will be enforced by the IdP as users are authenticated. Specifically, the “conditional access” feature limits access only to members of a group that you specify when you register your service. This feature is useful for services with simple access policies, and those unable to enforce access policies on their own.
The primary mechanism for logout is quitting the browser. When a user is done browsing, they can quit their browser to end their SSO session with the UW IdP. Doing so clears the cookies that maintain the session on their browser. Customers who integrate directly with the UW IdP can implement a local logout mechanism, and then redirect users to the UW IdP to display a consistent logout message.
- Self-service registration
Customers who integrate directly with the UW Identity Provider can use the UW Service Provider Registry for self-service registration, as well as to request attributes and access controls. Authorization to do so is based on ownership and control of DNS names for registered services. For example, if you control the domain name “service.uw.edu”, you can use self-service registration.
What user interactions are involved in SSO?
Sign in with UW NetID and sign in with 2FA describe basic user interactions with SSO, while Microsoft sign-in and Microsoft sign-in with 2FA describe interactions with SSO that start with Azure AD and involve the Microsoft sign-in process.
* support for OIDC isn’t generally available yet. Contact us if you’re interested.
** these items are included (without links) to encourage interested customers and early adopters to share and discuss their solution architectures.