New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

9.1: Pluggable Auth #23458

Closed
MTRichards opened this Issue Mar 21, 2016 · 24 comments

Comments

Projects
None yet
10 participants
@MTRichards
Contributor

MTRichards commented Mar 21, 2016

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
1

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.

@MTRichards MTRichards added this to the 9.1-current milestone Mar 21, 2016

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 22, 2016

Member

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

Member

PVince81 commented Mar 22, 2016

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

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke
Member

MorrisJobke commented Mar 30, 2016

Ref #21592

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 30, 2016

Member

Disable user, needs user table: #21282

Member

PVince81 commented Mar 30, 2016

Disable user, needs user table: #21282

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 30, 2016

Member
  • create ticket for integration of "remember me"
Member

PVince81 commented Mar 30, 2016

  • create ticket for integration of "remember me"
@MTRichards

This comment has been minimized.

Show comment
Hide comment
@MTRichards

MTRichards Apr 1, 2016

Contributor

Estimate: 3 weeks with L2 2 Factor Auth

Contributor

MTRichards commented Apr 1, 2016

Estimate: 3 weeks with L2 2 Factor Auth

@MTRichards

This comment has been minimized.

Show comment
Hide comment
@MTRichards
Contributor

MTRichards commented Apr 1, 2016

@cornelinux

This comment has been minimized.

Show comment
Hide comment
@cornelinux

cornelinux Apr 6, 2016

Contributor

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

Contributor

cornelinux commented Apr 6, 2016

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

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Apr 26, 2016

Member

@MTRichards related: 00005270

Member

butonic commented Apr 26, 2016

@MTRichards related: 00005270

@rperezb

This comment has been minimized.

Show comment
Hide comment
@rperezb

rperezb May 17, 2016

Member

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

Member

rperezb commented May 17, 2016

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

@ChristophWurst

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst May 17, 2016

Contributor

@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

Contributor

ChristophWurst commented May 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@MTRichards

MTRichards May 17, 2016

Contributor

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.

Contributor

MTRichards commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst May 17, 2016

Contributor

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

Contributor

ChristophWurst commented May 17, 2016

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

@MTRichards

This comment has been minimized.

Show comment
Hide comment
@MTRichards

MTRichards May 17, 2016

Contributor

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?

Contributor

MTRichards commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst May 17, 2016

Contributor

@MTRichards yes, it does. Thank you.

Contributor

ChristophWurst commented May 17, 2016

@MTRichards yes, it does. Thank you.

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 May 18, 2016

Member

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.

Member

PVince81 commented May 18, 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.

@cmonteroluque

This comment has been minimized.

Show comment
Hide comment
@cmonteroluque

cmonteroluque May 18, 2016

Contributor

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

Contributor

cmonteroluque commented May 18, 2016

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

@MTRichards

This comment has been minimized.

Show comment
Hide comment
@MTRichards

MTRichards May 18, 2016

Contributor

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:
68747470733a2f2f662e636c6f75642e6769746875622e636f6d2f6173736574732f313831383937372f323137353930352f35323438643735342d393563382d313165332d396464342d3365646265313437386638392e6a7067

Contributor

MTRichards commented May 18, 2016

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:
68747470733a2f2f662e636c6f75642e6769746875622e636f6d2f6173736574732f313831383937372f323137353930352f35323438643735342d393563382d313165332d396464342d3365646265313437386638392e6a7067

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 May 18, 2016

Member

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

Member

PVince81 commented May 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst May 23, 2016

Contributor

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

Contributor

ChristophWurst commented May 23, 2016

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

@ChristophWurst

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst May 23, 2016

Contributor
  • 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. -> owncloud/documentation#2450
Contributor

ChristophWurst commented May 23, 2016

  • 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. -> owncloud/documentation#2450
@ChristophWurst

This comment has been minimized.

Show comment
Hide comment
@ChristophWurst

ChristophWurst Jun 2, 2016

Contributor

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

#24779

Contributor

ChristophWurst commented Jun 2, 2016

For all new installed ownClouds enforce application specific passwords

This is not implemented yet, reopening.

#24779

@cdamken

This comment has been minimized.

Show comment
Hide comment
@cdamken

cdamken Jun 23, 2016

Contributor

@PVince81 Ref: #23458 (comment)

  • create ticket for integration of "remember me"

Is this part needed?

Contributor

cdamken commented Jun 23, 2016

@PVince81 Ref: #23458 (comment)

  • create ticket for integration of "remember me"

Is this part needed?

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81
Member

PVince81 commented Jun 23, 2016

not sure, @ChristophWurst ?

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Nov 13, 2017

Member

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

Member

PVince81 commented Nov 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment