Single sign-on with UW NetID


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 article describes web integration options for SSO with UW NetID. Authenticate your users describes options for other platforms.

Want some help? 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.

Web integration options

Pick an IdP guide

Web applications can be integrated with UW NetIDs and the UW Groups service via a variety of methods, including Entra ID and UW Shibboleth. UW Shibboleth and Entra ID are both generally recommended. Guide to which UW Identity Provider your web application should prefer:
Web app ... UW Entra ID UW Shibboleth
requires use of SAML or OIDC

X

X
requires use of WS-Federation or WS-Trust protocols

X

  
requires the OAuth protocol

X

  
requires integration with Office 365 or other Entra ID apps

X

  
requires user provisioning via the SCIM protocol

X

  
has an Entra ID application gallery template

X

  
requires support team access to app sign in logs

X

  
requires custom terms of use

X

  
requires Research and Scholarship category support  

X
requires custom IdP metadata  

X
requires multilateral SAML federation  

X
requires support for social identities such as Facebook

X

  
requires broadest possible set of identity providers

X

  
requires better user experience via sign in only when required

X

  
requires group claims for member-private groups  

X
requires claims involving confidential data  

X
requires simple conditional access controls such as: -group membership -IP address

X

X
requires advanced conditional access controls including: -location (IP, GeoRegion, or GPS) -device platform -client application -client device state -sign in risk -application specific restrictions

X

  
requires stronger fraud protections such as: -behavior analytics to flag risky signs in such as: atypical travel, unknown/suspect locations, patterns matching known compromised account signatures -detection of publicly leaked credentials -high volume of daily security signals

X

  

Web integration options

Follow these guides to integrate directly with the UW Shibboleth Identity Provider. You can integrate your services directly with the UW Shibboleth 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 Shibboleth 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 Shibboleth 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.
The Entra ID application integration guide is at: Entra ID Application Integration Guide - IT Connect (uw.edu)

Other Web SSO integration options

Customers can also integrate Web SSO through other IT services:

Other Web SSO options

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 for web applications.

Frequently asked questions

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.
The UW Shibboleth Identity Provider (idp.u.washington.edu) is a 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.
Entra ID provides a variety of cloud-based capabilities including application management, authentication, credential management, device management, information security, and is the integration point for a variety of cloud-based and hybrid solutions. Entra ID is Microsoft's cloud-based, infrastructure-as-a-service (IaaS) identity management solution. A document which explains a broad set of common terminology associated with Azure Active Directory may help you navigate. More information about the UW Entra ID is available at Entra ID - IT Connect (uw.edu).
If you integrate directly with the UW Shibboleth 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.
  • 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. 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.
  • Reauthentication 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. 2FA can be requested through standard SAML 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 The UW Shibboleth Identity Provider can enforce access controls (authorization) as users are authenticated, on a per-application basis upon customer request during service provider registration. The UW Shibboleth "conditional access" controls include IP address and group membership. This feature is useful for services with simple access policies, and those unable to enforce access policies on their own.
  • Logout 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.
If you integrate directly with the UW Shibboleth Identity Provider, you can rely on the following features:
  • Standards compliance The UW Entra ID supports open interoperable industry and community standards for SSO, like Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) (no restrictions), OAuth2, and SCIM, as well being used by the research and education community.
  • Default session can be indefinite in length For devices which have registered with Entra ID, your SSO session length is indefinite--only interrupted by security events, such as signing out, rebooting, or detection of risk. This maximizes the user experience, while still ensuring that security is maintained.
  • User attributes UW Entra ID can release a variety of user attributes, including identifiers such as UW NetID, names, group memberships, and more. Attributes are released using standard SAML. Attributes can be useful for access control decisions and personalization. UW Entra ID currently does not include any UW Confidential data, so groups with membership privacy are not available.
  • Reauthentication UW Entra ID can support forced reauthentication on a per application basis. Excess reauthentication can annoy users and is generally discouraged with UW Entra ID.
  • 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 mechanisms or it can be enforced by Entra ID itself, by requesting a conditional access policy. Note: many other controls can also be requested and enforced via an Entra ID conditional access policy.
  • Access controls The UW Entra ID can enforce access controls (authorization) as users are authenticated, on a per-application basis by requesting a conditional access policy. UW Entra ID conditional access controls include 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.
  • Logout If the client device is not Entra ID registered, the primary mechanism for logout is quitting the browser. If the client device is Entra ID registered, then the primary mechanism to logout for a specific application is to log out of device. Should a UW NetID be compromised, UW-IT centrally revokes that user's tokens which indefinitely grant access to Entra ID applications. This forces a fresh interactive sign in regardless of the client device state.
  • Self-service registration Customers can use Entra ID application registration for self-service registration of their application, as well as to configure attribute claims, and assign users. Conditional access policies, SCIM-based provisioning, and pre-integrated 3rd party vendor applications do require UW-IT assistance due to elevated permission requirements. See Entra ID Application Integration Guide - IT Connect (uw.edu) for more info.

* support for OIDC isn't generally available for UW Shibboleth yet--it is fully supported for UW Entra ID. Contact us if you're interested in using OIDC with UW Shibboleth. ** these items are included (without links) to encourage interested customers and early adopters to share and discuss their solution architectures.