Hi all, I'm wondering if this was ever submitted to the CAS code base.
I'm running CAS 5.2.7 and we are using DUO for MFA. Last week, migrated a vendor from Shibboleth to CAS for IDP services and the issue described here began to happen. The authn request is signed and in IE the total length of the URL exceeds 2083/2084 which, appear to be the limits for IE and Edge https://support.microsoft.com/en-us/help/208427/maximum-url-length-is-2-083-characters-in-internet-explorer When a user authenticates to this new service, authentication succeeds and they are forwarded to the duo challenge screen where the request dies unceremoniously. There are no messages in the CAS logs as the CAS service is waiting for the next action after the duo challenge is met. Conversely, I have another vendor that does not sign the auth requests, the URL that is forwarded to UI, during the DUO challenge, is shorter and the request goes through without a hitch. The issue doesn't appear to affect users who don't have MFA enable for this service or users that are required to use MFA when they use another browser. On Thursday, June 28, 2018 at 8:32:43 AM UTC-5, David Curry wrote: > > Here is the fix for the IE+SAML2+Duo problem: > > *** 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 > > -- > > DAVID A. CURRY, CISSP > *DIRECTOR OF INFORMATION SECURITY* > INFORMATION TECHNOLOGY > > 71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003 > +1 212 229-5300 x4728 • david.cu...@newschool.edu <javascript:> > > [image: The New School] > > > On Wed, Jun 27, 2018 at 5:16 PM David Curry <david...@newschool.edu > <javascript:>> wrote: > >> We ran into this as well. We submitted a patch to Duo, since the problem >> is in their code that exists for backyard compatibility with ancient >> browsers, but they were not interested. >> >> I'm not where I can get at it this evening, but I will post the patch >> tomorrow for you. It's basically a couple of line change to the Duo Web SDK >> JavaScript. We've been running it in production for a while now with no >> issues. >> >> >> David A. Curry, CISSP >> Director of Information Security >> The New School - Information Technology >> 71 Fifth Ave., 9th Fl. ~ New York, NY 10003 >> +1 212 229-5300 x4728 ~ david...@newschool.edu <javascript:> >> Sent from my phone; please excuse typos and inane auto-corrections. >> >> >> On Wed, Jun 27, 2018, 16:38 Richard Frovarp <richard...@ndsu.edu >> <javascript:>> wrote: >> >>> We're having issues with users using Microsoft browsers going through >>> MFA (specifically Duo) on SAML2 services. Against CAS/SAMLv1.1 services >>> they are fine. If they are already SSO'd in, they are also fine. >>> >>> It has to be some size limitations. The login URL for one of the >>> services is 6kb long with all of the SAML stuff shoved into the URL. Am >>> I missing a setting so that the CAS server holds onto that SAML2 info >>> instead of passing it through the URL? Shibboleth IdP doesn't require >>> these long URLs. My guess is that between the data being sent, and the >>> referrer, it's just too much. It's been a while since I looked at the >>> logs, but it looks like part of the request is being truncated going to >>> CAS, and thus CAS doesn't know what to do with it. I have thought about >>> sticking in the response header to tell the browser not to send the >>> referrer in order to drop that out of the equation. >>> >>> Any ideas? >>> >>> Thanks, >>> >>> Richard >>> >>> -- >>> - Website: https://apereo.github.io/cas >>> - Gitter Chatroom: https://gitter.im/apereo/cas >>> - List Guidelines: https://goo.gl/1VRrw7 >>> - Contributions: https://goo.gl/mh7qDG >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "CAS Community" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to cas-user+u...@apereo.org <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/cc93b571-b4fe-9746-3848-27b2b9f6176a%40ndsu.edu >>> . >>> >> -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/67f38b08-d64a-405e-b4b8-b74fd4f8e98e%40apereo.org.
