Single sign-on with UW NetID

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:

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)

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.

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.

• For UW Shibboleth, see Sign in with UW NetID and sign in with 2FA to find a description of the basic user interactions.
• For UW Entra ID, see Microsoft sign-in and Microsoft sign-in with 2FA to find a description of the basic user interactions.

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.