Make "open owncloud in browser" log on automatically

[jochenwezel]

The button "open owncloud in browser" currently opens the logon form in browser.

Like dropbox, the button should do a logon automatically

[danimo]

PR 2 requires to merge the pull request #42, which adds support for what you are asking via libattica (using OCS specs). This does not require to hand over sessions. On the other hand, opening a browser does.

[danimo]

This is waiting for owncloud/core#5453.

[LukasReschke]

Proposed process

1. User clicks on "Open ownCloud in browser"
2. Client sends request to /ocs/v1.php/cloud/capabilities to check whether the instance supports authentication based on authentication tokens
3. Client sends a POST request to /ocs/v1.php/auth/nonce to get a new nonce.
4. Server stores the nonce in the DB and assigns it to the specified user
5. When clicking on the "open in browser" button the client should either "send the user to the login endpoint e.g. "/auth/nonce?nonce=$nonce&user=$username" OR create a local HTML file that sends this data as POST request to the endpoint (preferred to not leak the username into the log - this is also how e.g. Dropbox implements this)
6. The server is then verifying the nonce and if the specified token is found the user is logged-in and redirected to the default application (e.g. files)

Acceptance criteria

Client

• Nonces SHOULD not be send via GET. POST should be used instead. (e.g. Dropbox does this via a local HTML file, the browser is then sent to file://var/foo/blah.html which is responsible for the POST request to the authentication endpoint)
• Nonces SHOULD be stored encrypted in the memory
• Nonces MUST NOT be stored unencrypted on the filesystem. It MAY be stored unencrypted for a short term period (e.g. the redirecing HTML file)

Server

• Already logged-in users MUST NOT be logged-out if a nonce for another user is sent
• Nonces MUST NOT be reusable
• Nonces MUST expire after a specific period (e.g. 1 hour)
• Requesting a nonce MUST NOT be vulnerable against CSRF
• Administrators MUST be able to disable this functionality
• Nonce-based authentication MUST work with the planned two-factor authentication capabilities
• Multiple nonces for a user MUST be supported.
• Users MUST be redirected to the specified default application in config.php OR a two-factor auth application
• Invalid nonces or reused nonces MUST be logged
• Nonces MUST be generated by a secure RNG

Considerations

While using a cryptographic generated token (e.g. HMAC) might be a solution that would not require requesting a nonce I see the drawback that once an attacker has the secret he is able to request tokens all the time even if you have changed the password. This is not desirable.
Furthermore, reusing the cookie is not an option since we do not want to leak it (e.g. to logs) and this might also be prone to a Session Fixation attack if implemented improperly on the server side. Let's solve this properly together :-)

Needed changes

1. Server needs to implement an API to request nonces
2. Server needs to implement an authentication endpoint for nonces
3. Client needs to implement those APIs

If we can agree on this implementation I'll begin working on the required change in core. Then we can finally make this happen ;-)

\cc @dragotin @guruz @ogoffart @danimo

[DeepDiver1975]

@LukasReschke sounds good to me - final question: is this part of core or an isolated app. Building it as an app would already cover the requirement to allow the admin to disable the functionality

[LukasReschke]

Implementing this as isolated application would be possible and makes - in my opinion - also sense. We should ship and enable it per default then.

@karlitschek

[danimo]

Sounds good from my side. Not sure about the 'encrypt nonce in memory' part, because this usually doesn't work as expected, even if you go down to C-level, and because encryption only means that some attacker that has access to the application's memory must look in two places to also find the key, which is not really a challenge. Am I missing anything?

[DeepDiver1975]

@LukasReschke sooner or later we will need some oauth mechanism as well - would it make sense to bundle the development of both features because both will touch the very core of the our auth mechanisms?

[LukasReschke]

@danimo You're obviously right, this is more or less an obfuscation measure that doesn't work with opensource software. That's how you end after reviewing applications where this is a key requirement. (You know, managers and banksters love snake-oil ;-))

@DeepDiver1975 I agree on the fact that OAuth is something important that we have to tackle for ownCloud 8 and should be in core. To be honest, the whole login system could need a rewrite. This change would be unrelated since this can be implemented without a complete reimplementation. But yeah, let's solve this together to avoid rewriting the nonce-based authentication in the future ;-)

[MTRichards]

I like the feature, it is a parity thing. Definitely nice to have, but does a lot for the end user experience.

[ogoffart]

Moved to backlog since this is waiting for a server support.

[ogoffart]

@DeepDiver1975 Is there a server issue to track the server part of this?

Edit: I re-opened owncloud/core#5453