*** Duo-Web-v2.js 2018-06-28 08:12:08.723891501 -0400
--- Duo-Web-v2-fix.js 2018-06-28 08:14:41.721450104 -0400
***************
*** 374,380 ****
// point the iframe at Duo
iframe.src = [
'https://', host, '/frame/web/v1/auth?tx=', duoSig,
! '&parent=', encodeURIComponent(document.location.href),
'&v=2.6'
].join('');
--- 374,383 ----
// point the iframe at Duo
iframe.src = [
'https://', host, '/frame/web/v1/auth?tx=', duoSig,
! '&parent=',
! (window.postMessage ?
! encodeURIComponent(document.location.href.split('?')[0]) :
! encodeURIComponent(document.location.href)),
'&v=2.6'
].join('');
Download the original source from
https://raw.githubusercontent.com/duosecurity/duo_java/master/js/Duo-Web-v2.js, and then either make the change above manually, or save it to a file and run "
patch -p0 < patch.txt". Feed the patched file to your favorite JavaScript minimizer (e.g.,
http://lisperator.net/uglifyjs/) and save the result. Then put the new minimized file in your Maven overlay at
src/main/resources/static/js/duo/Duo-Web-v2.js or, if you have configured your own theme (as we have), in
src/main/resources/static/themes/yourtheme/js/duo/Duo-Web-v2.js) and rebuild your WAR file.
We ran this patch without issues in test for about three weeks, and have been running it in production without issues since June 11th.
Explanation of the patch, if you're interested:
Basically, the problem is that as the web flow goes back and forth between CAS and the SP, the query parameters that CAS puts on the end of the URL get longer and longer. This seems to happen with all CAS/SAML2 services, but it's much worse when one or both sides of the SAML2 negotiation require signed and/or encrypted assertions; the URL with query parameters can grow in length to tens of thousands of characters.
Anyway, eventually you get to the point in the webflow where CAS sends casDuoLoginView.html to the user's browser. This is the page that includes the Duo Web SDK, a bunch of JavaScript that manipulates the iframe on the page that displays the Duo dialog. To populate the Duo iframe, the Web SDK constructs a source URL that points at the Duo back-end servers and includes as a query parameter the full URL of the CAS server including all of its query parameters. This is where the problem arises--because that URL is already really, really long, the resulting source URL calling back to the Duo back-end is even longer, and it exceeds the maximum length of a URL in Internet Explorer (2,083 characters) causing IE11 to silently fail, and so you end up with a blank iframe. (In our testing, Edge was also impacted, even though according to its documentation it should not have been.)
We reported this to Duo back in May (
https://github.com/duosecurity/duo_java/issues/4) and provided a simple one-line fix, which was just to truncate the query parameters off the CAS URL before sending it to the Duo back-end. The response back from the Duo engineer was that by doing that we "may experience breakage with any users using IE7 or other browsers that don't have
window.postMessage natively supported." Okay, so they're trying to maintain backward compatibility with ancient software for whatever reason.
Well, window.postMessage is supported by all modern browsers, and frankly, if someone is still using IE7, then the Internet is probably sucking for them in general already :-), so this wouldn't make it any worse. But okay, to help preserve their backward compatibility I suggested a slightly "smarter" version of the patch to the Duo engineer -- one that only truncates the URL if window.postMessage is supported by the browser (in which case it doesn't need the URL anyway). That's what the patch above does. But, I never got a response back to my suggestion, so I assume Duo has no intention of doing anything about this.
--Dave