[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreoffice-website] Authentication issue with Nextcloud
- Subject: Re: [libreoffice-website] Authentication issue with Nextcloud
- From: Guilhem Moulin <firstname.lastname@example.org>
- Date: Sat, 23 Mar 2019 00:44:47 +0100
- To: William Gathoye <email@example.com>
- Cc: firstname.lastname@example.org
On Fri, 22 Mar 2019 at 22:32:02 +0100, William Gathoye wrote:
> It appears the location of these fonts haven't been whitelisted properly
> leading to the Nextcloud client webview (qt5-webengine) to not load them
> to avoid a potential XSS vulnerability.
The CSP violation looks somewhat odd to me:
[unknown Refused to load the font 'https://auth.documentfoundation.org/saml/singleSignOn?SAMLRequest=…' because it violates the following Content Security Policy directive: "font-src 'self' data:".
There is no CSP for font resources on https://auth.documentfoundation.org .
(In fact the page doesn't have any font resource AFAICT, although I suppose
it might depend on the User-Agent.) On https://nextcloud.documentfoundation.org
Content-Security-Policy: default-src 'none'; […]; font-src 'self' data:; […]
I don't understand why your client tries apply that policy when loading
resources from https://auth.documentfoundation.org . There is a 303
redirection in the middle, and the CSP doesn't apply to the Location
Also, the CSP is populated by Nextcloud itself. Plugins can amend it,
for instance instance ‘richdocuments’ adds the LOOL domain to the
If ‘user_saml’ was really non-functioning without loading font resources
from the SAML IdP URI (even if just on desktop clients), I would expect
somewhere in the source.
> 2. *not* successful, http result code is 302  --> the connection
> issue per se
That's rdm#2658 right? If so, please avoid cross-posting.
> Could you please disable "Use SAML auth for the Nextcloud desktop
> clients (requires user re-authentication)" in the Nextcloud server admin
> settings? SAML SSO remains active without this parameter.
it's not exactly clear to me what that would entail.
* Does that require authentication via application-specific passwords?
If so, changing the setting requires some kind of consensus, and if
users agree to disable SAML, we need a transition (and warn users)
to avoid confusion. You're not the only one using the desktop
client against out instance, and most other folks are using a
version that seems to work. AFAICT disabling the setting would make
their setup stop working until they add an app password. (I guess
they won't object if they can have long-lived sessions, but they
still need to be consulted and warned.)
* Does it mean that the Nextcloud server hijacks the SAML challenge
and perform authentication on behalf of the user? (Doesn't seem so
based of my understanding of the code, but I'm not sure.) If so,
that would completely collapse the threat model. WebSSO isn't only
a convenience, the different front-ends don't get to see user
credentials. Reducing the attack surface is the whole point.
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
|Re: [libreoffice-website] Authentication issue with Nextcloud||William Gathoye <firstname.lastname@example.org>|
|[libreoffice-website] Authentication issue with Nextcloud||William Gathoye <email@example.com>|
- Prev by Date: Re: [libreoffice-website] Fixing broken links for previous LibreOffice releases
- Next by Date: Re: [libreoffice-website] Authentication issue with Nextcloud
- Previous by thread: [libreoffice-website] Authentication issue with Nextcloud
- Next by thread: Re: [libreoffice-website] Authentication issue with Nextcloud