MS Edge/IE issues with SAML2 + Duo

93 views
Skip to first unread message

Richard Frovarp

unread,
Jun 27, 2018, 4:38:19 PM6/27/18
to CAS Community
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

Misagh Moayyed

unread,
Jun 27, 2018, 4:45:28 PM6/27/18
to cas-...@apereo.org
https://github.com/duosecurity/duo_java/issues/4

What issues?

--Misagh
> --
> - 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.
> 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.

David Curry

unread,
Jun 27, 2018, 5:16:50 PM6/27/18
to cas-...@apereo.org
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 x4728david...@newschool.edu
Sent from my phone; please excuse typos and inane auto-corrections.
   

David Curry

unread,
Jun 28, 2018, 9:32:43 AM6/28/18
to cas-...@apereo.org
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 x4728david...@newschool.edu

The New School


Andrew Marker

unread,
Sep 5, 2018, 10:15:56 AM9/5/18
to CAS Community
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


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.

David Curry

unread,
Sep 5, 2018, 11:24:22 AM9/5/18
to cas-...@apereo.org
I did not submit our patch to the CAS code base because, frankly, it's not a CAS bug.

It's a bug (or at least poor design) in the Duo Web SDK that interacts negatively with a poor design decision made by Microsoft in the implementation of Internet Explorer and, for reasons known only to them, preserved in Edge.

I submitted it to Duo, but they declined to make the change for backward compatibility reasons (the conditional in the patch solves the backward compatibility issue, but they still weren't interested).

--Dave


--

DAVID A. CURRY, CISSP
DIRECTOR OF INFORMATION SECURITY
INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 212 229-5300 x4728david...@newschool.edu

The New School


Andrew Marker

unread,
Sep 5, 2018, 11:45:52 AM9/5/18
to CAS Community
That all makes sense to me. I doesn't really help with selling the technology stack and, generally speaking MFA to our constituents. A little angst isn't all bad; It's just a little bad.  

Thanks for the prompt reply and for originally uncovering this.

David Curry

unread,
Sep 5, 2018, 11:49:49 AM9/5/18
to cas-...@apereo.org
For what it's worth, we've been running with the locally-patched version of the Duo Web SDK  since June 11th and have not had any issues with it at all.

--Dave

--

DAVID A. CURRY, CISSP
DIRECTOR OF INFORMATION SECURITY
INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 212 229-5300 x4728david...@newschool.edu

The New School


Andrew Marker

unread,
Sep 6, 2018, 12:22:07 PM9/6/18
to CAS Community
Hi Dave,

I've implemented the patch on our pre-prod systems. The constituent testing and my own confirms that this does indeed resolve the issue: 
 
* For users of: IE/Edge
* That need to use CAS to authenticate
* For services that sign their SAML auth requests
* Where the service requires MFA or for a service that that we the IDP require MFA 
* Where the MFA provider is DUO 

We've had two widespread outages for the our community members who are required to use DUO because, even though we'd configured the service for fail/open, the response was just delayed for minutes and evidently in the versions of CAS we are running there doesn't appear to be a timeout, configurable or otherwise for this MFA service.

As we are on the cusp of a campus wide roll out, these things matter. I'm down with the disdain for the use deprecated code, but adoption is better than principle (at least in this case....)  

The conditions above are not that uncommon and the legitimate fear of using deprecated code can be mitigated by testing to verify that the function exists and if it doesn't use the preferred method until the issue is resolved by a future release of the Edge product (assuming MS chooses to address it). I'll discuss making a similar recommendation to DUO with the parties here that deal with them related to our contract.

Again thanks for the assistance.

Andrew
Reply all
Reply to author
Forward
0 new messages