Fallback Authentication with SPNEGO does not work

[shubjit]

Describe the bug
When Liberty configured with SPNEGO, Fallback Authentication (or Fail Over to Application Authentication) when Liberty application is accessed from Non Domain systems does not work. Following Error is shown on the browser CWWKS4306E: SPNEGO authentication is not supported on this client browser..

No specific logs recorded.

Steps to Reproduce

• Windows 2019 or 2022 Datacebter setup as Domain Controller with Active Directory and KDC (Kerberos)
• Download and install Liberty version 23.0.0.6
• Deploy snoop application for LIberty and Configure it with LDAP registry server (Active Directory on KDC)
• Configure SPNEGO with krb5.ini and krb51.keytab file provided from the KDC server
• Access the snoop URL from a client machine connected to the Domain - WORKS
• Access the snoop URL from a non domain client machine - FAILS

As a workaround If we enable an authfilter to skip non domain machines for example for Mac OS, it works, <userAgent id="spnegoWebAgent" agent="Mozilla|Opera" matchType="contains"/>

Expected behavior
Failover to App Authentication with SPNEGO config should work. It works on Traditional WebSphere Application Server.

Diagnostic information:

• OpenLiberty Version: 23.0.0.6
• Affected feature(s) [ spnego-1.0]
• Java Version: IBM java 8.0.8.5 ( java.runtime = Java(TM) SE Runtime Environment (8.0.8.5 - pwa6480sr8fp5-20230418_01(SR8 FP5))
• server.xml configuration

  <spnego id="mySpnego"
     disableFailOverToAppAuthType="false"
     trimKerberosRealmNameFromPrincipal="true"
     includeClientGSSCredentialInSubject="true"
     krb5Config="C:\keys\krb5.ini"
     krb5Keytab="C:\keys\krb51.keytab"
     servicePrincipalNames="HTTP/hostname.domain.com"
     authFilterRef="myAuthFilter"
  />
  <authFilter id="myAuthFilter">
    <userAgent id="spnegoWebAgent" agent="Mozilla|Opera" matchType="contains"/>
  </authFilter>

Additional context
None

[wrodrig]

Hi @shubjit

Thanks for reaching out. Our team has been working to recreate the problem that you reported. Unfortunately we are not seeing fallback on macOS that are not domain joined with either Open Liberty or Traditional WebSphere. Based on the traces we've collected, the browser doesn't seem to be handling the request correctly. This suggest that what you are seeing is a browser problem rather than a Open Liberty or Traditional WebSphere issue.

Since you mentioned that you are seeing this working with Traditional WebSphere, we were wondering if you could provide us the browser name and version that you are using. This will help us to see if there has been some changes.

You are also welcome to also open a Support Case with our team and reference this issue.

We look forward to continue supporting you.

[shubjit]

Thank you for your response @wrodrig

While we dont have a working Traditional WebSphere setup, we tested further on the existing Liberty setup. You are right, it seems specific to browser and OS. Here was our test results, seems like fallback auth fails on Firefox browser on Windows and All browsers on MacOS.

On Non-Domain joined MacOS

• All Browsers Fallback auth FAILS - Safari, Firefox and Chrome

On Windows Non-Domain joined System:

• Chrome and Edge Browser - Fallback Auth Works
• Firefox - Fallback Auth FAILS

On Windows Domain Joined System:

• Firefox with browser configured with steps from below link- SPNEGO Auth WORKS https://openliberty.io/docs/latest/configuring-spnego-authentication.html

• Firefox with browser NOT Configured - Fallback Auth FAILS

• Chrome with browser configured with steps from below link -SPNEGO Auth WORKS https://openliberty.io/docs/latest/configuring-spnego-authentication.html

• Chrome with browser NOT Configured - Fallback Auth WORKS

For now we can filter out MacOS Client access with this filter, but non domain joined Windows client have no workaround. <userAgent id="spnegoWebAgent" agent="Mac OS" matchType="notContain"/ >

[wrodrig]

Hi,

Thanks for your response, I agree that targeting Windows clients that are not domain joined will be challenging. One suggestion that I can give you is that if your domain joined machine share a similar ip address, you can consider using the remoteAddress filter option. But this doesn't necessarily work on every system.