Infrastructure

FWIW it's irrelevant whether the credentials are stored in LDAP or in some other backend. Since late February our Nextcloud instance doesn't “use LDAP authentication” anymore (and until mid-March access wasn't granted to all TDF members by default, it was done on a per-user basis), but Single Sign On (via SAML token); session expiration is a property of the latter, not of the authentication backend.

For what it's worth, it works for me using the owncloud client (‘owncloud-client 2.4.1+dfsg-1.1’ package from Debian sid). So clearly the “we are now unable to connect to the instance using any desktop or mobile app client” is incorrect :-P Also, as mentioned on IRC, note that we upgraded to Nextcloud 14 on Sep 12, so before you opened this ticket. Did you upgrade your client recently? With 2.4.1 I'm not redirected to the page asking to grant access.

IIRC where was a bug in the Nextcloud client (with an existing bug ID),
because I heard that in the past too, that the ownCloud client works.
Didn't try myself though, so it's hearsay.

https://github.com/nextcloud/desktop/issues/830

If someone can check on the server whether this could be related to the E2E module? This would be fine.

The main issue however persists. The SAML token doesn't survive a client restart. And when we create an app password from the Nextcloud webui, we cannot use the app password.
Here are the client logs when I try to do so:
https://gist.github.com/wget/1cfb8a1d13eac9f0280d42b7dae59703
Also, (worse!), it appears each time we connect usin SAML, a dedicated app password is created. The previous ones are NOT invalidated and I'm pretty sure we can still login with them! When I checked my settings page I had dozens of generated tokens!
I asked this very same question to the nextcloud packager of Arch Linux. He appears to be great at fixing bugs and upstreaming the fixes.

Thanks for chasing that!
Did you hear anything back from the Arch Linux maintainer?

Florian Effenberger wrote:

Thanks for chasing that!
Did you hear anything back from the Arch Linux maintainer?

Yes, he is fixing bug related to the webview (the regression), but the community in the desktop app is pretty slow. Owncloud is much better in this regard.

Rrgarding SAML auth, he canot help us narrowing down the issue, because he has no SAML server account to test. Could we maybe give him an account on the TDF instance and ask him if he can help us?

Otherwise I'm afraid we will have to wait for FOSDEM in order to debug this issue. We will have Nextcloud devs at hand ;D We will just have to launch a broadcast message to reach some of them :D

Thanks for chasing this!
IIRC the ownCloud app can be used as well, but not entirely sure
Talking at FOSDEM sounds great indeed, looking forward to :-)

Can you check with Guilhem if we can give him a test account without
access to private data? Should be possible, and if so, happy to help him
narrow down the problem, of course!

Florian Effenberger wrote:

Any updates on this one, is the upstream bug maybe fixed?

Hello Florian,

The problem is still being discussed upstream but seems to be on hold for now. Upstream seems to be looking for testing instances where this bug is reproducible. This is why I asked Guilhem about the ability to clone our Nextcloud instance to a dedicated VM (without the files obviously) where we could nuke and try to test things out from OUR side (and ask maybe the Nextcloud broader community if they have any clue in the case we cannot achieve anything from our end).

• Guilhem discussed the PHP code handling the SAML authentication on Nextcloud
• And I mentioned the ability to disable the option "Use SAML auth for the Nextcloud desktop clients (requires user re-authentication)" that has been discussed upstream where people were saying this was fixing the issue. But we want to test this out first to see if this isn't breaking any thing. This is why a test instance based on our configuration (a clone of our instance) would come in handy.

William Gathoye wrote:

This is why I asked Guilhem about the ability to clone our Nextcloud instance to a dedicated VM (without the files obviously) where we could nuke and try to test things out from OUR side (and ask maybe the Nextcloud broader community if they have any clue in the case we cannot achieve anything from our end).

Just cloning our Nextcloud deployment won't do, Nextcloud, the LDAP DIT, and the SAML (LemonLDAP::NG) instances are tightly coupled and there are severe privacy concerns if we don't want testers to browse the DIT freely, or worse impersonate users. The DIT needs to be populated with dummy data, key material re-generated, X.509 chains re-requested and re-deployed, and password reset and re-deployed. Probably worth having a low-risk test harness for that at some point, but since none of this it's done it's a way bigger work than merely cloning Nextcloud with an empty database :-/

Would it be an option to grant some trusted Nextcloud contact a regular
temporary user access to our instance, like we do for community members
too, or do they need much more access permissions to chase the bug?

Florian Effenberger wrote:

Would it be an option to grant some trusted Nextcloud contact a regular
temporary user access to our instance, like we do for community members
too, or do they need much more access permissions to chase the bug?

Playing with the production instance is a bit tricky, because we don't know whether the options we want to test could introduce regressions. (This is the purpose of the test).

Actually, I know from a privacy perspective cloning the prod to dev could be not in balance with GDPR privacy laws etc, but I think this is the only viable solution. In order to limit the risk, instead of having all the users, we can clone the prod, only keep a small subset of its users (like Arnaud Versini and me) and restrict that instance to TDF only without giving access to the wider Nextcloud community.

I know you're busy and cloning the prod to a dev environment might involve some work and spend some of guilhem's precious time, but this is for the sake of open source software :)

Actually, I know from a privacy perspective cloning the prod to dev
could be not in balance with GDPR privacy laws etc, but I think this is
the only viable solution. In order to limit the risk, instead of having

That sounds like a huge time investment, tbh, but Guilhem correct me if
I'm wrong and it's a trivial task.

If not, maybe it helps already to let them know our configuration and
setup so they can have a closer look? I don't mind giving them a regular
test account on our instance, but investing large amount of time right
now is rather not possible from my POV.

Hello everyone,

I'm pleased to announce latest commits of the Nextcloud Desktop app (for v 2.6.0) are fixing the issue.
- https://github.com/nextcloud/desktop/issues/1084#issuecomment-536203455
- https://github.com/nextcloud/desktop/issues/830#issuecomment-536203420

I'm pretty sure we can finally close this issue now :)

Regards,

Thanks for chasing this! ;)