9.1: Pluggable Auth

[MTRichards]

Manage authenticated connections

Requirements
User should be able to view signed-in and recently used devices
User should be able to revoke access for a device
Should be compatible with existing authentication backends

UX Example

Technical implementation

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.

1. User installs client
2. User clicks on Authenticate
3. Website with ownCloud login window is displayed
4. User authenticates
5. Client gets back a device specific password that can be used to login

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.

Disable user

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.

Recommendations

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

Requirements
Logging in using configured E-Mail address should be possible

Technical implementation

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:

1. User enters E-Mail address into ownCloud
2. ownCloud Server contacts Global Lookup Server and gives:
   a. Instance ID
   b. Instance URL
   c. Username
   d. E-Mail address
3. Global Lookup Server sends a mail to the user with unique key in it.
4. User clicks on the link
5. Global Lookup Server sends a cryptographically signed (we have a CA in ownCloud since 9.0 ) HTTP request to the ownCloud Server confirming that the user has confirmed it’s mail address.

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 

Recommendations

Can be done. Needs to be looked into together with the user account table.

Steps:

1. Implement server-side “Kill session” approach
2. Add application specific passwords and config switch
3. Make clients authenticate using the application specific password.
4. For all new installed ownClouds enforce application specific passwords
   This is required so we don’t break any existing Cal-/CardDAV etc. clients. New users would have to generate a new application specific password.

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.

[PVince81]

@LukasReschke can you add a link your magic tickets where you described your ideas ?

[MorrisJobke]

Ref #21592

[PVince81]

Disable user, needs user table: #21282

[PVince81]

• create ticket for integration of "remember me"

[MTRichards]

Estimate: 3 weeks with L2 2 Factor Auth

[MTRichards]

@LukasReschke

[cornelinux]

Does pluggable authentication also allow external authentication sources like described here?
https://github.com/privacyidea/AuthModuleRequirements

[butonic]

@MTRichards related: 00005270

[rperezb]

@owncloud/qa should we start creating the test plan?

[ChristophWurst]

@MTRichards @cmonteroluque session tracking, invalidation, application specific passwords as well as token based authentication were added in #24189. Is the GUI requirement for 9.1 too?

cc @MorrisJobke as you said you could help with the GUI part

[MTRichards]

Yes, we need the UI to make this usable for a typical admin, and for the users to get their tokens in the personal page.

[ChristophWurst]

@MTRichards what do you mean? What UI is needed for admins?

[MTRichards]

Sorry, that would be a step 2 - where admins can help a user remove a device token. To start, it is enough for the user to have the personal page option.

Does that make more sense?

[ChristophWurst]

@MTRichards yes, it does. Thank you.

[PVince81]

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.

[ghost]

Is there a circumstance where an admin would need to see multiple tokens simultaneously? Otherwise a search may be enough?

[MTRichards]

We might be able to add something to the user page, so we can leverage the existing user search / filter. Then a "devices" button opens a list of the existing tokens for that user, and each could be handled by the admin there.
Borrowed screenshot from a long time ago:

[PVince81]

@MTRichards adding a button in the users page would make sense, yes.
I'm less worried about the extra button but more about the extra view/list that needs to be opened, whether a new page, pop up, sidebar, etc... will need design.

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.

[ChristophWurst]

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

[ChristophWurst]

• We must also not forget to update documentation and drop an email to the dev mailing list to inform devs about the new auth mechanisms. -> https://github.com/owncloud/documentation/issues/2450

[ChristophWurst]

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

#24779

[cdamken]

@PVince81 Ref: #23458 (comment)

• create ticket for integration of "remember me"

Is this part needed?

[PVince81]

not sure, @ChristophWurst ?

[PVince81]

Raised #29548 as follow up for letting an admin terminate users' sessions.

[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.