External Storage Interface: Selecting Username and Password Options

[MTRichards]

As an admin, I want to be able to select one of four credential options so that when users log into ownCloud, the appropriate authentication mechanism is used for external storage connections.

The four are:

• Shared Login => "Username and password": Using credentials entered in the external storage line when the storage is initial configured (and the default)
• User Entered => "User entered, store in database": creates an error message when user logs in and user enters, then stored in db External Storage Interface: Trigering user username and password Entry #16302
• User Login => "Log-in credentials, save in session", Session https://github.com/owncloud/sharepoint/issues/159
• User Login => "Log-in credentials, save in database", DB https://github.com/owncloud/sharepoint/issues/159
• Global credentials (added by @PVince81): "Global credentials" auth backend for external storages #21991

Acceptance Criteria:

• Shared Login essentially uses a superuser name and password entered by the admin to mount the external storage. login is stored int he db in as secure a method as possible
• User Entered stored in the database in as secure a method as possible.
• User Login, session means that the credentials are only stored in the session and not captured in the database. This also means that a checkbox "allow sharing" for this external storage line item cannot be checked since the credentials are not stored anywhere.
• User login, DB means that the user's credentials are grabbed at login and stored in the database in as secure a method as possible.
• these are all offered for each external storage login

Edit by @PVince81: added the new wording

[PVince81]

I guess this only applies to system-wide mount points, the ones that admin setup for all users ?
Or should it apply to personal mounts as well ?

The tricky part here is that if the admin sets up a system mount point to "User entered", then we need to find a place where to store the user entered password. In any case, it looks like it's a good opportunity to move the ext storage configuration from "mount.json" to a proper database structure.
It would be too dangerous to save the user-password into "mount.json" every time a user enters a password, due to concurrency. (several processes writing to this file at the same time might explode)

Here is the ticket about revamping the data structure for external storages: #11261

[PVince81]

Allowing to select an authentication type also means that every storage backend needs to be adapted to support any of these. I'd suggest having each backend implement specific methods from which the username/password can be injected from outside by whichever auth mechanism was selected.

CC @Xenopathic @icewind1991 for additional input

[RobinMcCorkell]

@PVince81 That's the BackendService work I started over at #15914. I got a bit sidetracked with exams between then and now... Feel free to push to that branch, anyone who wants to help.

I was trying to think of the best way to design the OOP structure for authentication methods. The best I've come up with so far:

Interfaces for each authentication type (e.g. IPassword), implemented by different classes (e.g. Auth\UsernamePassword, Auth\OCPassword) and registered with a AuthenticationMethodService or equivalent. Then a backend defines which interface(s) it supports, and it gets passed the selected authentication object through $params['authObject'] or something. This is the Strategy pattern.

Only issue with this is that the AuthenticationMethodService will have to iterate through all registered authentication types to find which match a backend's defined interfaces, unless we can store a map of authentication interfaces to authentication implementations.

[PVince81]

Cool, thanks for the info.
At some point we will need to clean up the dust off your PR then 😄

[RobinMcCorkell]

Self assigning as part of #15914

[RobinMcCorkell]

So, session-based credentials and basic username/password are currently already implemented. Next, I'll implement store-in-DB user credentials, followed by the shared credentials.

[PVince81]

@MTRichards can you elaborate the workflow for shared login ? Who does what when ?

"Using credentials entered in the external storage line when the storage is initial configured"
I guess that can already be achieved this way: Admin creates a storage entry on the admin page, selects "applicable: all". This way all users (or specific groups) already get access to that storage.
If that was not the idea, in what way does the new approach differ ?

[MTRichards]

Hello @PVince81

"Using credentials entered in the external storage line when the storage is initial configured"
I guess that can already be achieved this way: Admin creates a storage entry on the admin page, selects "applicable: all". This way all users (or specific groups) already get access to that storage.
If that was not the idea, in what way does the new approach differ ?

That is the idea. Perhaps oddly worded...but this is the single account shared for all users indicated for that external storage.

[PVince81]

@MTRichards there's a problem with "User Login, store in Session": it makes it impossible to run any cron tasks on that storage (occ files:scan or others) because the credentials won't be available.

So either we should get rid of that option and favor "store in DB" or add a big warning that tells that some important functionality might not be available.

[MTRichards]

No choice but to keep it. Storing passwords in databases is a big no go for many of our customers, so for them we need to be crystal clear on the options and the implications.

@PVince81 won't the scan on access setting in the config file pick up these files, albeit quite slowly and when something is accessed?

@carlaschroder
Probably something we need to document - for external storage, when you select the "User Login, Store in Session" option, sharing will not work, and neither will filescanning in the background.

[PVince81]

@MTRichards scan on access through web UI or sync client will work. The problem is for any cron job or CLI tool that requires access to the storage, like the "occ files:scan" command.

[MTRichards]

Got it. If the user is not in with an active session, or even if they are (since we can't access the session veriable) we can't access the storage from any ownCloud server Cron initiated job.
Got it.

[icewind1991]

User Login, DB: #18531
User entered: #21790

[PVince81]

Thanks @icewind1991

[PVince81]

• TEST: what happens with different LDAP user id formats when using "Login credentials"

[PVince81]

@MTRichards looks like we missed the option "Global credentials" in this list ?
The tricky part about this is that if we add a field "Global credentials" like for WND, these would/could be global to ALL external storages, not only WND. Do we want that ?
If not, then we need to find a way to migrate the globally entered credentials from WND into the "Shared Login" mode.

CC @jmaciasportela @icewind1991

[jmaciasportela]

We have global credentials at admin level (unique) and user level (unique per user). Both can be shared between different mount points.

From files_external perspective has no sense to be the same credentials for every backend. I think that should be different for each backend.

[PVince81]

If we want to have this different for each backend, it means we need a more complex form that lets you map credentials to every backend, with only one set of credentials allowed for each one.

[jmaciasportela]

I'm afraid so. The other solution, is to change this in the migration script, to adapt old config to the new available.

[RobinMcCorkell]

IMO it actually does make sense to have Global Credentials affect all storages. The primary usecase for it is when there are many storages that are all accessed with the same username/password, hence the network is running an identity server. It is highly likely that the identity server is connected to all services available on the network, regardless of the exact backend (SFTP, SMB, WebDAV etc), so they all use the same credentials -> Global Credentials.

In the home user scenario, Global Credentials won't be that useful anyway

[MTRichards]

Global credentials was simply meant as a shortcut for an admin so they didn't have to type the credentials in more than once.

Use case was this: Admin enters global credentials, and then on a per mount point basis they select if the global credentials should be used in the drop down credentials list, or something else.

Use case for users: They enter the global credentials once in the personal page, and then can select on the mounts whether to use these global credentials or some other form of authentication.

Just to be clear, global credentials are a convenience and nothing more - you can get to the same result by just typing in user names.

So do we need a better form, or just this as an option in the dropdown list of credential options?

[RobinMcCorkell]

Perhaps there is a way to avoid having a separate authentication mechanism (= mroe complexity) and have something which solves the problem in a different way?

The problem is that an admin/user must type in a username/password for each individual storage, which becomes problematic when there are many storages that need configured. What about, when a 'Username/password' is filled for the first time in a session, and a second one is created, then that username/password is copied to the second storage as a default value? So the flow would be: admin/user creates a storage, sets username/password on it. Admin/user creates a second storage, username and password fields already set to the same as for the first storage (modifyable if necessary). That still gives the benefit of reduced typing for much lower complexity.

@MTRichards @PVince81 @DeepDiver1975 thoughts?

[icewind1991]

That would make changing the credentials hard

[PVince81]

@Xenopathic I think as an admin I would find this behavior strange, as if it was a bug or the browser remembered the login like it happened sometimes.

Having a field to storage global credentials is fine but the question is whether it's global to all backends (at least those supporting "username and password") or whether it should be per-backend.

Also another question technically is where to store this, should we reuse the table we just created for credentials or use a new one ? We probably also need new REST endpoints to be able to read/write these.

[RobinMcCorkell]

@PVince81 see #16305 (comment)

We can store the information in the CredentialsManager

[PVince81]

Discussed with @MTRichards and @jmaciasportela, the decision is to do the following:

• introduce a new "global credentials" auth backend
• there is only one set of credentials that applies to ALL backends that support the username/password scheme
• the migration from the WND config will not use this field: the global credentials from WND are moved to "custom credentials"

[PVince81]

Raised here: #21991

I've also updated the main ticket to add a bullet point for it.

[PVince81]

All authentication backends were added.

• QA: Testing external storage new auth functionality QA#101
• documentation: [files_external] Document new authentication backends owncloud-archive/documentation#2139

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.