Authentication test plan

[PVince81]

Based on what needs to be retested for owncloud/core#30157

• Regression testing: authenticate then webdav operation to confirm it works
  • cadaver (no session)
  • web browser + Webdav uploads
  • desktop client
  • mobile client
  • same with regular password
  • same with app password
  • shibboleth
  • oauth
  • impersonate app
  • test upgrading with active app password / session ?
• same as above but add a lock-out feature:
  • brute-force protection with fail2ban which parses logs
  • LDAP/Active Directory lock out

[SamuAlfageme]

Some interesting scenarios to be tested:

1. Creating and consuming a password (either app. password or an OAuth2 secret token)
2. Deleting/modifying those auth. items with active sessions (even password; based on @dercorn [10.0.4] Sessions created from application passwords result in "Login failed" errors when used core#30157 (comment))
3. Verify Inconsistency between OAuth2 access token and session cookie expirations core#28707 does no longer reproduces (in essence, the same scenario as 2)

[PVince81]

• also test the totp as it was reported that it might be broken here 10.0.6: WebDAV is broken core#30341

[thommierother]

If you need help with regression tests, I have a test installation ready except for shibboleth/LDAP/AD external auth providers.

[PVince81]

Tarball is ready for testing: https://download.owncloud.org/community/testing/owncloud-10.0.7RC1.tar.bz2

[thommierother]

first glimpse: carddav syncing on android works again, detailed report follows later today...

[SamuAlfageme]

Regression testing: N/A after owncloud/core#30398

Target: 10.0.7 RC1

Scenario Description:

1. Generate an application password
2. Consume the password for the following types of login
3. Observe for "Login failed" errors on apache/owncloud logs

(Application passwords are regenerated after each test)

Results:

Login Type	Result	Comments
Cadaver (no sessions)
Browser + Uploads	✅	-
Desktop client (new endpoint)	✅	-
Mobile clients (old endpoints)
Shibboleth
OAuth2	❌	There's still one 'Login failed' entry See owncloud/core#30157 (comment)

Lock-out specific scenarios

🔒 We still need infrastructure support cc/ @owncloud/devops

About the orthogonal scenarios described on #529 (comment)

1. Is covered by the previous tests
2. Delete an auth item:
   • Password (change)
   • OAuth2 "Authorized Clients" ✅
   • Application Passwords ❌ - "Disconnect" application password should kill its open sessions core#28553 still valid
3. 🔒 On hold, until Bugfix/owncloud/oauth2#103 core#30365 + Throw an exception if the Bearer header holds an invalid token oauth2#112 are tested

[patrickjahns]

We still need infrastructure support cc/ @owncloud/devops

what do you exactly need?

[SamuAlfageme]

@patrickjahns see #529 (comment) 's "same as above but add a lock-out feature" points and check the auth_backend_lockouts etherpad/#qa channel on rocketchat.

[thommierother]

Can someone check if I got the test cases right, I would do the tests this evening:

Login Type	PW Type	Result	Comment
Cadaver shell login	standard	Succcessful
Cadaver shell login	App password
Browser Login	standard
Browser Login	App password (with Oauth2 activated)
Client Upload	standard
Client Upload	App password (with Oauth2 activated)
Mobile Client Upload	standard
Mobile Client Upload	App password (with Oauth2 activated)
Mobile Client CalDAV	standard
Mobile Client CalDAV	App password (with Oauth2 activated)
Mobile Client CardDAV	standard
Mobile Client CardDAV	App password (with Oauth2 activated)

Mobile Client CalDav/Carddav is https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib&hl=de and https://play.google.com/store/apps/details?id=org.dmfs.carddav.sync&hl=de. All tests will be against an installation with encryption module.

[SamuAlfageme]

@thommierother that's pretty much it, yup!

Just remember to apply the owncloud/core#30398 patch on the tarball contents to go over the OAuth2 scenarios.

[thommierother]

Test results for https://download.owncloud.org/community/testing/owncloud-10.0.7RC1.tar.bz2 including owncloud/core#30398, with activated encryption

Login Type	PW Type	Result	Comment
Cadaver shell login	standard	Succcessful
Cadaver shell login	App password	Succcessful
Browser Login	standard	Succcessful
Browser Login	Oauth2 & TOTP activated	Succcessful
Client Upload	standard	Succcessful	Client 2.4.0 (build 8911).
Client Upload	Oauth2 & TOTP activated	failed	Sync is blocked with „503 Service Unavailable“
Mobile Client Upload	standard	Succcessful	Client 2.6.0 Android
Mobile Client Upload	Oauth2 & TOTP activated >> App Password	failed	Client requires Oauth & TOTP PW upon account creation. „Encryption not ready, Private key missing for user“ message
CalDAV Client	standard	Succcessful	CalDav/CardDav Sync Android Endpoint: remote.php/dav/
CalDAV Client	Oauth2 & TOTP activated >> App Password	Succcessful
CardDAV Client	standard	Succcessful	CalDav/CardDav Sync Android Endpoint: remote.php/dav/
CardDAV Client	Oauth2 & TOTP activated >> App Password	Succcessful

Only partly successful. The user story for „activated Oauth2 & TOTP and login through app password“ is still not correct. In this case, the mobile client should require no TOTP when the app password is used instead.

Moreover, encryption should still be possible for these scenarios. Upon creation of the account, the client should request the standard password AND the app password once. The app password should disable the TOTP requirement for the client. The client should still send the standard password to allow server encryption/decryption. The linking between standard and app password should be active as long as the app password is valid.

[SamuAlfageme]

Moreover, encryption should still be possible for these scenarios.

Your failed scenarios can be attributed to owncloud/oauth2#105; do not assess OAuth2 together with encryption just yet, please.

[thommierother]

I thought that already ... IMHO owncloud/oauth2#105 should have high priority because installations that used encryption in earlier releases would not like to switch back again (like me) ...

[SamuAlfageme]

Current testing status: 10.0.7 RC1 + owncloud/core#30398 + owncloud/core#30365 + owncloud/oauth2#112 = Still raises one (1) 'Login failed' exception when using application paswords to authenticate via OAuth2

[thommierother]

good luck ;-)

[PVince81]

• Please also add LDAP where user id is different than login name to the test plan

Reason: https://github.com/owncloud/core/pull/30365/files#diff-9c47cee6ac987e5256aeee509f91ddb1R291

[thommierother]

I see activity on the https://github.com/owncloud/core/tree/bugfix/owncloud/oauth2%23103 for example. Will there be a RC2 tarball this week for testing?

[PVince81]

@thommierother yes. The PR is currently going through CI and after it's merged we'll build RC2

[thommierother]

@PVince81: perfect ;-) Question about the process: does it make sense if I add my own test plan or just follow one of those created by @jesmrec ?

[PVince81]

RC2 built, it will appear here shortly once mirrors catch up: https://download.owncloud.org/community/testing/owncloud-10.0.7RC2.tar.bz2

[thommierother]

Re-tested for 10.0.7. RC2. owncloud/oauth2#105 is still open and blocks these use cases:

Client Upload to crypted storage with Oauth2 & TOTP activated, Sync is blocked with „503 Service Unavailable“

Mobile Client Upload with same settings shows „Encryption not ready, Private key missing for user“ message

[PVince81]

added entry in original post: "impersonate app"