Has anyone found a solution for IWA fallback to forms auth that works well with Chrome and Firefox?

[Josh Coffman]

We have a pre-authentication javascript which checks an IWA protected XML file, if it succeeds, it forwards a user through an IWA auth scheme. If it fails, it sends the user through a forms based auth scheme.

 

This all works well in IE. However, when the preauthentication JavaScript fails to grab the XML file in Chrome and Firefox, it brings up the dreaded Windows Username and Password dialog box.

 

We are trying to find a pre-auth mechanism for each of the three major browsers. We would like to avoid having users see the Windows Auth dialog box at all costs.

 

Right now, the only guaranteed solution we have found is to fallback to forms immediately if the browser is not IE. This seems like a waste, because IWA works well in Chrome, it just doesn't behave when it fails.

 

Thanks!

 

- Josh

[Anon Anon]

What are the conditions for Chrome/FF sometimes working and sometimes not working?  Could the same user sometimes work and sometimes not work? Is it always based on a browser setting or physical access to the network or something else?

Wondering if you could set a cookie under certain conditions and then check for the cookie before trying IWA with Chrome/FF.

Worst case is Chrome/FF users might see the pop-up once vs. every time.

 

Something like:

 

if IE

-grab xml file

else

check for cookie

if cookie ...

 

the "if cookie..." really depends on the possible use cases.

[Chris Bertagnolli]

One way that I've played with, but not finalized, is actually doing the call within a background frame/object to do the entire authentication flow.

 

So rather than seeing a bunch of 'redirects' the user simply sees a "doing SSO" type message while all the action takes place behind the scenes. If successful, sends them on to application. If unsuccessful, fall-through to log in form flow.

 

Hasn't really been real-world tested but initial checks I don't get the domain pop-up in any browser whether on wrong domain or off the domain.

 

-------

 

Now if the domain pop-up isn't a huge concern, can also handle up-front Kerberos 'check' . Only done this with IIS though. So basically the initial auth scheme used by application is a 'false forms' to a degree that points to a folder protected by "Negotiate:Kerberos".

 

If that fails, a custom error page is invoked which snags the target application and sends them through the log in form flow. If it succeeds, then the 'form' that now loads sends them through the SiteMinder Kerberos flow.

 

This can generate the pop-up though if user is not on the domain or different domain and has IWA enabled in browser (so off-site employee or something that's not on a VPN). But other than that works for IE, Safari, Chrome, Opera and Firefox.

[Josh Coffman]

We have all of the code written to maintain the target, and fall back to forms when things fail. IE works seamlessly. We are using the model where we have a JavaScript that performs a get on an IWA protected file, if it fails, we go to forms, if it succeeds we go to a windows auth scheme. This all works well in IE. However, even though the preauth is performed in javascript "outside" the browser window, users are still getting the pop-up in chrome and firefox when the preauth fails for any reason, be it network connectivity the IWA servers, dns failure, au/az failure on the iwa resource, etc.

 

The requirement is that the pop-up dialog never is seen. we need to trap all causes of that pop-up.

 

The background frame object is intriguing. I will research that, but it seems like it would still pop up a dialog if it fails.

[Chris Bertagnolli]

Yeah I can't swear to the frame, haven't been able to do a full 'proper' setup and testing yet. But had a note here that pop-up didn't 'pass-through' the frame. When I get back to it and get some more detailed testing will give you an update if you haven't already made further progress .

 

 

Other plus side to the frame is if you need to do SAML within it. Since objects etc won't follow SAML redirects/posts (at least that I've seen), this will. So if you had like a SAML IdP doing the Kerberos auth, or anything else in the background, all of it seems to be followed properly.

[AaronBerman]

You may want to take a look at the validation site.  The development team has released a video of an upcoming feature to do windows fallback to forms.

Windows Fallback to Form Validate Project