Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
9.1: Pluggable Auth #23458
Manage authenticated connections
The typical implementations differentiate between “Sessions” and “Devices”, the differentiation being there that “Sessions” are usually initiated actively by a user while a “Device” will be constantly connected.
Login using session
The “Session” will be used for anything that logs in using the browser. Basically after a login we store some User Agent data and the last activity of a session, the primary key will be the session ID.
If a user clicks “Revoke” on the session in the user interface it’s session ID will be deleted from the DB and the session will not be used anymore. (even though it is still existent on the DB)
One big problem that we will face here is the fact that ownCloud uses a ton of sessions. Basically a third-party DAV client will waste a session for each connection and this would totally swamp the interface. Thus we need to destroy all sessions for anything that authenticates against DAV except the ownCloud clients.
Login using client
Devices are usually logged-in using a device specific password. The login process would look as following.
Step 3 here is required to have full integration with any kind of authentication provider, also covering any second factor authentication.
The device specific password is then stored in the ownCloud database and can be used to login as specified user. Once this password is removed the client will have lost its connection to the ownCloud server.
Remark: To keep compatibility with regular DAV clients there will be the possibility to generate an application specific password manually. This is basically the same token as the automatic process above would create. In this case the user just uses this password to authenticate.
It also has to be possible to disable user accounts. This “disable user account” mode needs to be implemented anyways for the “Migrate user to Object Storage” use-case. This can be re-used here and implemented using an OCC command line utility.
Incompatibilities and their resolution
This will be incompatible with external storages that are configured as “Log-in credentials, save in session”, this are the same limitations that we’re facing with sharing etc.
Personally my suggestion would be in such cases to store the password encrypted in the database with the application specific password. If we just store a hash in the database for the application specific password brute forcing them is also not possible.
A malicious admin can access the data only if the client is connected. This is the same that we have at the moment as well. So no new threat model.
Another incompatibility that we’re going to face is the fact that the user password could be changed from an external backend, such as LDAP. This is an already existing problem which will at the moment also trigger bugs and make data inaccessible. (since the client will reuse a session at the moment as well)
To address this the stored password should be validated all 5 minutes against the external user manager. If it doesn’t match the stored token will be invalidated and the user has to relogin.
While not a perfect solution it is anyways better than the status quo and also matches the requirement that once a password has been changed existing clients should be logged-out as well.
Managing sessions generated by a browser is doable only in core. This can be added without any client modifications. For also allowing disconnecting a client we need to do some modifications there as well.
My recommendation here would be to implement this all server-side already; this would allow users to remove browsers as well. In addition, we can add the application specific passwords GUI so that users can also remove clients on their own. For security conscious administrators we can already then add a config switch to only allow authentication against the DAV endpoints using such a token.
We can then gradually adjust our clients to support this kind of authentication. As a FINAL future step we can adjust the clients to request a device specific token and delete the user credentials, then we can set the config switch to this value by default for new installations. (to not break existing clients, if somebody wants to do that on an existing value they just need to overwrite the config value manually)
For users there would thus be no user interaction required and we can gradually increase the security of our clients.
Login with E-Mail
The actual storage of the e-mail address is to be discussed and to be determined whether this matches together with the “User Account Table” topic. In any case, we can’t use the appconfig table due to performance and security concerns. (e.g. SQL Column Truncation)
Before an e-mail address is added we must also verify its ownership by sending a mail address to it with a link to verify it.
Remark: We could also leverage this in combination with an (optional) global user lookup if we really wanted to. Basically this could work this way:
This way we have verified that a user owns an e-mail address and can also use that for a potential global user lookup. There are some things to consider like being registered on multiple instances (show multiple entries) and unregistering (regularly check whether ownCloud server is still there and offer logout) but besides that this would theoretically work.
Note that this is just a crazy idea for the future and not actually part of the requirements here
Can be done. Needs to be looked into together with the user account table.
Remark: This also fixes the long-standing problem that we face with things like Shibboleth (Clients need to re-authenticate all the time). Basically we would use Shibboleth only to generate a valid token once and then the device specific token would be used.
Does pluggable authentication also allow external authentication sources like described here?
referenced this issue
May 6, 2016
Also note that in the case of the personal page, we can assume that the list of tokens won't be too long, so it might not need extra logic for pagination/search.
However for an admin, we can't just list every user's token out there and would need more logic and potentially a more advanced UI to be able to select/search users first.
@MTRichards adding a button in the users page would make sense, yes.
Now thinking of the users page, aren't there user managers that don't provide a list of users, like shibboleth and others ? In these cases the user list might not even be searchable. Might need a plain field where a user name can be input with autocomplete, but also accepts any value.