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:

• a MIT Kerberos realm (u.washington.edu)
• NETID Active Directory (netid.washington.edu)

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:

• UW Shibboleth
• Azure AD

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:

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.