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.