January 7, 2019 – Entries in this brick are overdue for review and updates; new options have entered the environment, other options have changed names, and some have new lifecycle designations.
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.
The following table categorizes related technologies according to their current lifecycle status.
(Trends to watch)
(Scheduled for retirement)
- TLS Client Certificate Authentication (personal certificates)
- UWWI Windows Azure Active Directory
- Facebook Login
- Yahoo OpenID
- LinkedIn API
- WS-Federation (Passive Requestor Profile)
- Google OpenID 2.0 Directed Identity protocol
- UWWI Active Directory Federation Services (ADFS)
- UW Google Apps OpenID Federated Login Service
- UW Social-to-SAML Gateway
- InCommon Social-to-SAML Gateway
- InCommon Federation Discovery Service
- Shibboleth Service Provider 3.0.4 and later
- SAML 2.0 (Web Browser SSO Profile)
- Windows Authentication (Kerberos, NTLMv2)
- UW Shibboleth Identity Provider
- UW Service Provider Registry
- InCommon Federation
- UWWI Active Directory Domain Services
- Shibboleth Service Provider 3.0.3 and earlier
- Non-Shibboleth SP implementations of SAML 2.0
- LDAP Authentication (over SSL)
- UW Windows Live ID Authentication
- Kerberos version 5
- TLS Client Certificate Authentication (using application certificates from the UW CA)
- Other proprietary web SSO protocols
- UWWI Active Directory LDAP Authentication Services (over SSL)
- UW Kerberos Service
- UW Services CA (for application certificates used by users)
- Pubcookie (all versions)
- SAML 1.1
- LDAP Authentication (without SSL)
- UW Pubcookie Login Server
- Pubcookie Server Registration
- UWWI Active Directory LDAP Authentication Services (without SSL)
- Windows Authentication (NTLMv1, LM)
Note: Refer to the IAM Brick Reference for complete descriptions of the six status designations and common lifecycle patterns.
- 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.
- 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 UWWI 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.
- 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 UWWI Active Directory, rather than as option for individual web sites.
- 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.
- OAuth 2.0 and OpenID Connect need to be evaluated further, but as open standards for internet identity they are likely to meet strategic needs and fit in the baseline along side of Shibboleth and SAML protocols within five years.
- Windows Identity Foundation (WIF), WS-Federation and WS-Trust are under "tactical" status due to their adoption within strategic projects in UW-IT (e.g. Office 365, Dynamics CRM). WIF is a library of .NET Framework classes used to create "claims-aware" applications, including user authentication and obtaining identity information. It may emerge as a baseline solution for .NET developers if demand warrants additional investment for support. Without additional investment, it will likely remain under "tactical" status with community models of support or transition to "containment" status to limit uses to funded projects.
- 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.
- The UW and InCommon Social-to-SAML gateways are under "tactical" status while the proof of concept is evaluated further. If these gateways prove to be useful and cost-effective solutions for consuming social identity from social identity providers without the cost and complexity of additional protocols besides SAML, then they may transition to "baseline" status.
- 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.
- 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).
- 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.
- LDAP Authentication (over SSL) via UWWI 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.
- 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.
- 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.
- 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.
- 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.
- Pubcookie Retirement Plan – all support and technical services are being retired. The proprietary (non-standard) web SSO protocol has been overtaken by open standards, and the related open source project has been dormant for several years.
- 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.
Last Review Date
March 20, 2013