Authenticate your users

Authentication is the process of verifying who someone is. How you implement authentication depends on your user community and the technologies you use to deliver services to them. Although you can authenticate nearly anyone in the world—not only members of the UW community, but also users from other academic institutions and social networks—how you authenticate them depends on the technologies you choose to use.

Want some help?
Need help understanding how authentication fits into your service or how to authenticate users consistent with applicable policies? Contact us for assistance.

Resources on user authentication by use case

The following resources describe more specific approaches to user authentication based on the use cases involved.

Unix or Mac native applications generally use one of two Kerberos solutions in concert with a group solution. Customers often integrate with Kerberos using PAM (Pluggable Authentication Module) modules. Kerberos solutions include:

The Linux Directory Infrastructure is often used to integrate with UW Groups.

Windows native applications use Kerberos and NTLM to authenticate UW users usually via the NETID Active Directory. Customers may also use domain/forest trusts, delegated OUs, and Azure Active Directory to enable Windows native applications. NETID Active Directory supports UW NetIDs for Windows servers, workstations, and lab computers using the “netid.washington.edu” domain. Azure Active Directory enables single sign-on with UW NetID for Windows native applications that rely on the Microsoft sign-in.

Network devices can be authenticated via RADIUS. RADIUS authentication supports eduroam wireless network access and access to network devices. Support for customers outside of UW-IT is limited.

Native mobile applications such as an iOS or Android application can be authenticated via a variety of options, most often using the same solutions under web authentication. Feel free to contact us to discuss strategies for authenticating users of native mobile applications.

Web applications, including custom-built applications, open source, vendor software, and software-as-a-service applications can integrate with UW NetIDs and UW Groups via two solutions:

For more information on deciding between these two, see ‘Picking the right web identity provider solution’.

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

Resources to extend user authentication to fit your purpose

Add 2FA: IT system owners and their teams can add two-factor authentication (2FA) to their systems by integrating with UW-IT infrastructure for UW NetIDs and authentication. Customers primarily integrate 2FA through the web application solutions noted above, but limited support is available for direct integrations with departmental systems.

Authenticate users from outside the UW: For web application use cases, a variety of solutions exist. For other use cases, there are very few viable, secure solutions.

If using UW Shibboleth, InCommon and eduGAIN are federations that enable you to authenticate users from other universities without having to sponsor UW NetIDs for them. To enable safe, secure access between organizations and the trusted exchange of identity data, these federations establish technology standards and baseline expectations for participating organizations, including service providers that host and manage access to resources, institutions that authenticate members of their local communities (like the UW), and federation operators (like InCommon) and cyberinfrastructure (like CILogon) that connect participants and communities. Authenticating users from other academic institutions can be combined with SSO with UW NetID, and social login too.
If using UW Shibboleth, the UW Social to SAML Gateway enables authentication using social accounts (Google, Facebook, GitHub, etc.). Social login enables you to authenticate users outside the UW community without having to sponsor a UW NetID for them. Social login can be combined with UW NetID, InCommon, or eduGAIN. Instructions are provided for customers for configuring Shibboleth SP to use the UW Social Gateway.
If using Azure AD, you can invite a user to be a guest in the UW Azure AD tenant. You don’t need to do any pre-configuration nor determine what their existing authentication solution might be. No federation configuration, no social gateway configuration needed. Just send them an email-based invite. Most Azure AD applications make this experience simple.