[MODLOGSAML-134] SSO configuration fails with error "not XML" if IdP URL returns content-type is "text/xhtml" (mod-login-saml) Created: 15/Mar/22  Updated: 20/May/22  Resolved: 02/May/22

Status: Closed
Project: mod-login-saml
Components: None
Affects versions: None
Fix versions: 2.4.5

Type: Story Priority: P2
Reporter: Lisa Sjögren Assignee: Julian Ladisch
Resolution: Done Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2022-03-15-12-25-52-474.png    
Sprint: CP: sprint 138, CP: sprint 137
Development Team: Core: Platform
Release: Morning Glory (R2 2022)
RCA Group: TBD

 Description   

Overview:
Validation of IdP metadata fails when an IdPs metadata URL has a content-type that does not contain the string "xml". Failure to validate prevents you from saving the settings, and thus configuring SSO at all.

This is currently preventing SSO configuration for Wellesley College, whose metadata has content-type "text/xhtml". they are using a service called Duo for their SSO, and do not have the option of reconfiguring the content-type.

For Wellesley to be able to use FOLIO SSO the validation would need to accept "text/xhtml".

This request:
https://okapi-bugfest-kiwi.folio.ebsco.com/saml/validate?type=idpurl&value=https%3A%2F%2Fsso-c1bd2609.sso.duosecurity.com%2Fsaml2%2Fsp%2FDIW9G5WEO32MZZF6J8VO%2Fmetadata

returns

{
    "valid": false,
    "error": "Response content-type is not XML"
}

Looking closer, you can see that the content-type of https://sso-c1bd2609.sso.duosecurity.com/saml2/sp/DIW9G5WEO32MZZF6J8VO/metadata is indeed "text/xhtml"

curl -i https://sso-c1bd2609.sso.duosecurity.com/saml2/sp/DIW9G5WEO32MZZF6J8VO/metadata
HTTP/2 200
date: Tue, 15 Mar 2022 11:41:13 GMT
content-type: text/xhtml
content-length: 2559
server: Duo/1.0
etag: "e6323085147e62c182dfcc804accde6d0b17dbbf"
content-disposition: inline
strict-transport-security: max-age=31536000
x-frame-options: DENY
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
content-security-policy: default-src 'none'; style-src 'self' https://uw1.pwl.login.duosecurity.com; script-src 'self' https://uw1.pwl.login.duosecurity.com; font-src 'self'; frame-src 'self'  ; frame-ancestors 'none'; img-src 'self'   https://uw1.pwl.login.duosecurity.com; connect-src 'self' https://uw1.pwl.login.duosecurity.com

Steps to Reproduce:

  1. In Kiwi Bugfest, go to Settings > Tenant > SSO settings
  2. In the field Identity Provider URL, type https://sso-c1bd2609.sso.duosecurity.com/saml2/sp/DIW9G5WEO32MZZF6J8VO/metadata
  3. Fill in the other properties with anything and hit save.

Expected Results:
Your new settings are saved.

Actual Results:
The settings cannot be saved, as the IdP fails FOLIO's validation. Note the error message: "This is not a valid Identity Provider URL"

Additional Information:
The code that performs the validation is here: https://github.com/folio-org/mod-login-saml/blob/f1767d3a6f4d0d990e07c5ce324bc42dd98e05c6/src/main/java/org/folio/util/UrlUtil.java#L28
Validation was implemented here: https://folio-org.atlassian.net/browse/MODLOGSAML-27

Interested parties: Wellesely College (Kara Hart & gravishanker@wellesley.edu)



 Comments   
Comment by Brooks Travis [ 22/Mar/22 ]

I think this is a P2. It's not a blocker, but the only workaround is not really feasible in the medium-to-long term.

Comment by Brooks Travis [ 25/Mar/22 ]

Going ahead and assigning this to Core: Platform. We need to get someone's eyes on it.

Comment by Anya [ 28/Mar/22 ]

Support: Craig McNally should this ticket come to Tech council to see if we want text to come through, does this have any security issues or implications.  Lisa Sjögren do we know if this impacts more than just Wellesley? 

Comment by Lisa Sjögren [ 29/Mar/22 ]

Anya I have not hear of this impacting anyone except Wellesley yet – AFAIK not any library that we have worked with.

Wellesley are using what I understand to be a rather common SSO provider in the US, though – Duo. So it would be interesting to know if this issue would be shared by other institutions using SSO from Duo or if it is somehow unique to Wellesley's Duo setup.

Comment by Craig McNally [ 30/Mar/22 ]

I believe this is a relatively simple fix.  I think it would only involve adjusting this conditional:  https://github.com/folio-org/mod-login-saml/blob/f1767d3a6f4d0d990e07c5ce324bc42dd98e05c6/src/main/java/org/folio/util/UrlUtil.java#L28

That said, we'd have to try it.  It's possible that the underlying pac4j-saml library wouldn't like the text/xhtml content-type either.  I took a quick peek at the pac4j-saml code and don't see anything like that but I didn't do an extensive search either. 

 

Comment by Anya [ 04/Apr/22 ]

Support: Cornell uses Duo, and SSO, and they have had no issues... could this be a local configuration issue? 

CC Craig McNally, Lisa Sjögren

Comment by Lisa Sjögren [ 05/Apr/22 ]

Thank you, Anya! I will check again with Wellesley.

Comment by Julian Ladisch [ 11/Apr/22 ]

Is

content-type: text/xhtml

an HTTP header line with a valid content-type?

For HTTP/1.1 the spec is RFC 2616 section 3.7: https://datatracker.ietf.org/doc/html/rfc2616#section-3.7 :
It says that media-type values are registered with the Internet Assigned Number Authority (IANA).

For HTTP/2.0 the spec is RFC 7540 section 8.1.2: https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2 :
It refers to the "Message Header Field" registry maintained at <https://www.iana.org/assignments/message-headers>.

IANA maintains the list of registered media types: https://www.iana.org/assignments/media-types/media-types.xhtml

It contains

text/xml
application/xml
application/xhtml+xml
application/samlmetadata+xml

but it doesn't contain

text/xhtml

See also https://datatracker.ietf.org/doc/html/rfc3023#appendix-A.1 : "use of text/xml or application/xml to label discrete media types will hinder correct dispatching and general interoperability."

mod-login-saml is a security sensitive module. Therefore external input like IdP metadata must be validated, filtered, or sanitized because it might be hostile data.

Comment by Julian Ladisch [ 11/Apr/22 ]

Kara Hart: Can you ask the sysops of https://sso-c1bd2609.sso.duosecurity.com/saml2/sp/DIW9G5WEO32MZZF6J8VO/metadata to fix the content-type header line?

Changing

text/xhtml

to any of the registered values

text/xml
application/xml
application/xhtml+xml
application/samlmetadata+xml

will fix the issue.

Comment by Julian Ladisch [ 13/Apr/22 ]

Lisa Sjögren, Kara Hart : Do you need a mod-login-saml hotfix, or can you continue to use your workaround and try to get it fixed at sso-c1bd2609.sso.duosecurity.com?

I block this issue until we get a response from Wellesley.

Comment by Lisa Sjögren [ 14/Apr/22 ]

Thank you Julian Ladisch! I had noted the same thing about text/xhtml not being included in lists of valid content-types, and it is very useful to have your insights into the practical and security implications of this.

Kara Hart Would you be able to double-check with your IT department if there is any chance of correcting this on your side – either doing it yourselves, or by contacting Duo support? The fact that Cornell are also using, and their metadata comes with a valid content-type, raises some new hope that this might be configurable.

The only "workaround" available I can think of is for librarians to continue logging into the FOLIO admin interface using their FOLIO login and password.

Comment by Lisa Sjögren [ 14/Apr/22 ]

Cornell has clarified that they are using Dup for 2FA, not SSO – so that glimmer of hope has been extinguished now.

Comment by Kara Hart [ 14/Apr/22 ]

Hi Julian Ladisch ,  Our DUO tech says the DUO setting cannot be altered.  So we do need the change in accepted content types in FOLIO if possible. 

Comment by Oleksii Petrenko [ 18/Apr/22 ]

Moved to Morning Glory release.

Julian Ladisch suggest that FOLIO's security team raises an issue (CVE) against Duo software. We might need a temporary fix in FOLIO.

Comment by Julian Ladisch [ 02/May/22 ]

Duo says at https://duo.com/support/security-and-reliability/security-response :

"Security Reports We Are Not Interested In"
"Security best practice concerns"
"Missing HTTP Headers"
"Duo Security Integrations that default to fail-open/fail-safe behaviors"

Duo doesn't care about appropriate technical measures that are state of the art. Duo and institutions using Duo could be in violation of GDPR Article 32 and similar laws and policies.

Therefore it is wasted time to file an issue at Duo.

mod-login-saml v2.4.5 has been released with this workaround:

The "Content-Type: text/xhtml" header is accepted provided that there exists a "Server: Duo/1.0" header. This doesn't affect the security of institutions that don't use Duo.

Comment by Lisa Sjögren [ 05/May/22 ]

Thank you Julian Ladisch for putting this targeted workaround in place for institutions using Duo, and for looking into the possibility of Duo addressing this on their side.

Comment by Brooks Travis [ 05/May/22 ]

Hope none of Wellesley’s students, faculty, or staff ever use their systems from Europe… 😎

Comment by Julian Ladisch [ 20/May/22 ]

mod-login-saml v2.4.5 is a patch version that will automatically been included in all flower releases that use mod-login-saml v2.4.*.

2022 R2 Morning Glory GA: https://github.com/folio-org/platform-complete/blob/master/install.json

2022 R1 Lotus Hot Fix #1: https://github.com/folio-org/platform-complete/blob/R1-2022/install.json

2021 R3 Kiwi Hot Fix #3: https://github.com/folio-org/platform-complete/blob/R3-2021/install.json

Generated at Thu Feb 08 22:22:22 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.