Web Authentication Brick

Description

Web authentication service options provide user authentication and web single sign-on (SSO) to web sites operated by customers.

A customer implements web authentication by selecting an option that fits the needs and constraints specific to a given web site.

Status Table

The following table categorizes related technologies according to their current lifecycle status.

Note: Refer to the IAM Brick Reference for complete descriptions of the six status designations and common lifecycle patterns.

Comments

• Emerging
  1. Social identity providers like Facebook, Microsoft (via Windows Live IDs and Microsoft Accounts), Yahoo, and LinkedIn are emerging into the environment for web authentication, particularly for UW web sites that need to consume social identities and are looking to do so via technical services like Facebook Login, Yahoo OpenID, and LinkedIn API.
  2. Some social identity providers can be used to authenticate UW users with UW NetIDs via the cloud-based identity services tied to contracted instances of services like Google Apps and Office 365. Technical services deployed with these instances, like MI Windows Azure Active Directory  may extend UW NetID authentication to 3rd party service provider web sites. For example, see UW Google Apps OpenID under "tactical" status.
  3. TLS Client Certificate Authentication using personal user certificates may forever be listed as an emerging option. Widespread adoption for web authentication remains unlikely. However, use of client certificates may be useful for authenticating users to the Weblogin service or to MI Active Directory, rather than as option for individual web sites.
  4. WebAuthN provides passwordless authentication via asymmetric (public-key) cryptography.  The user who is authenticating would typically have their keys stored on physical token (USB device) or on the users device itself (Windows Hello).  This landed in Firefox 60 and Chrome 67.  Microsoft is providing full support of this in Edge on Windows 10  (using a YubiKey) with AAD via FIDO2.
• Strategic
• Tactical
  1. Use of the OpenID Federated Login Service tied to UW Google Apps has emerged as a tactical way for members of the UW community to log in to 3rd party service provider web sites based on UW NetID authentication. There are no plans to turn off this capability tied to UW Google Apps. It is tactical because support is limited for this capability, although use is becoming more prevalent among users familiar with the user interaction.
  2. OAuth 2.0 has emerged as a thriving open standard for internet identity and is commonly used with the OIDC standard. Use today at the UW is via UW Azure AD and UW Google Apps, but other technical services may emerge.
• Baseline
  1. Shibboleth Service Provider (SP) software is "baseline" status because it is based on industry- and community-standards for identity federation and web SSO, and also because it supports important features like a consistent, verifiable user-login experience, session reauthentication, token (2-factor) authentication, authorization and privacy, as well as support for multiple trusted identity providers. Shibboleth SP software is open source software that's widely adopted and deployed internationally and in the U.S. research and education community and recommended by the InCommon federation for participating members like the University of Washington. The UW Service Provider Registry and InCommon Federation support customers using Shibboleth SP software, through self-service registration and federation metadata services.
  2. Windows Authentication has "baseline" status because it is a de facto standard solution for authenticating users to web applications hosted on Internet Information Services (IIS) or to other web applications that rely on the Microsoft Windows platform. Windows Authentication supports two underlying authentication protocols, Kerberos and NTLM. It is also known as Integrated Windows Authentication (in IIS 6.0).
• Containment
  1. Non-Shibboleth software implementations of SAML 2.0 are under containment to reduce documentation and support costs. Customers can use other software implementations of SAML 2.0, but advice and support for registration, configuration, and troubleshooting is limited. 
  2. LDAP Authentication (over SSL) via MI Active Directory LDAP Authentication Services is under "containment" status because its use for web authentication often requires users to provide their passwords to service provider web sites, rather than to trusted identity provider web sites like the Weblogin service.
  3. UW Windows Live ID Authentication is under "containment" and is expected to transition to "retirement" status once the UW cloud program develops strategies related to use of Microsoft accounts to support Office 365. Although the Windows Live IDs created through the UW Windows Live service are based on UW NetID identifiers, they are provisioned with a different, user-selected password, and therefore authentication isn't tied to UW NetID password authentication.
  4. Kerberos is under "containment" status for web authentication because its use often requires users to provide their passwords to service provider web sites, rather than to trusted identity provider web sites like the Weblogin service.   
  5. TLS Client Certificate Authentication using application certificates issued by the UW Services CA to identify users is under "containment". Some web service developers are using application certificates to identify themselves to test client authentication to REST APIs. This particular use of application certificates is not recommended for production services, and it isn't scalable. Therefore support is very limited. It will be deprecated when cost-effective alternatives are available.
  6. Other proprietary web SSO protocols are under "containment" status to control costs and promote industry- and community-standards. Customers working with software vendors who cannot integrate with baseline solutions can work with UW-IT consulting services to explore implementation options and strategies.
  7. The UW and InCommon Social-to-SAML gateways are under "containment" status. Limited use and lack of adoption across Higher Education led to this capability moving from "tactical" to "containment".  Applications are best served by creating direct/native SSO integrations with social platforms.
  8. WS-Federation and WS-Trust have transitioned from tactical to containment status. They were tactical due to adoption via strategic projects in UW-IT in the past (e.g. Dynamics 365 on-premises), however, no other significant interest has emerged to suggest these protocols should have anything other than containment status.
  9. NETID ADFS is accepting no additional relying parties and awaiting a project to retire the small use remaining after completion of the Unfederate Azure AD project as of 7/13/2021. All existing ADFS relying parties are expected to shift to Azure AD which supports the WS-Federation and WS-Trust protocols.
• Retirement
  1. Use of protocols such as HTTP Basic without SSL and LDAP without SSL that verify passwords via unsecured network connections are strongly deprecated and will be retired. They also warrant retirement due to their reliance on the "password anti-pattern" requiring users to provide passwords to unusual login user interfaces.
  2. NTLMv1 & LM were retired 8/12/2014 from the NETID Active Directory
  3. Azure AD App Proxy is scheduled for retirement 2/2/2022
  4. Windows Identity Foundation (WIF) left supported status from Microsoft on 4/14/2020.

References

• - empty -

See Also

• Network Authentication Brick
• REST API Authentication
• Mobile Authentication Brick

Last Review Date

March 20, 2013