ChristophWurst commented 8 years ago

Overview

With some identity providers (e.g. shibboleth SSO), the user logs in on an external web page which on success authenticates the user for ownCloud. As the client needs a browser window for that and desktop clients are planning to remove those (see https://github.com/owncloud/client/issues/4798), we need to find a generic way to authenticate clients on external services and create a device token if the authentication succeeds. Instead of a built-in browser an external one should be used.

Basic workflow

Step 1. Determine auth mechanism

C -> S: Client sends unauthenticated request to a defined endpoint E1
S -> C: Server responds with a list of possible auth mechanisms (basic, token, browser-based)

If basic auth is used -> send HTTP header 'Authentication: basic username:password' If token auth is used -> send HTTP header 'Authentication: basic username:token' or 'Authentication: token xxx' if #24763 was implemented.

Step 2. Request login URL + temporary token

C -> S: Client requests URL + token from defined endpoint E2 (and specifies provider?)
Server creates temporary token and saves it to the DB
S -> C: Server returns URL for the external browser and the temporary token

Note: the URL must contain the temporary token, so that the identity provider redirects the user back after successful login (or if the user was already logged in).

Step 3a. Open browser window for user and let her/him authenticate

Client opens browser window and shows the URL returned by the server
User logs in on that page, which then redirects back to a defined endpoint E3
On the redirected endpoint, the database entry of the temporary token is updated to reflect the login status

Step 3b. Polling the auth state from the server

C -> S: In the background, the client polls the server on a defined endpoint E4 using the temporary token
S -> C: As soon as the login was finished, the server creates a device token (app specific password) and returns it. The temporary token/database entry can be deleted.

Step 4. Use the token

The returned token can then be used for authenticating requests (sent as header)

This will also allow to connect sync clients to accounts which are two-factor enforced. There we can use ownCloud itself as 'identity provider' and let the user solve the 2FA challenge. We could even go one step further and do the login purely in a browser, even if no 2FA or special identity provider is used. This would be an interesting login mechanism for untrustworthy clients you don't want to enter your password.

HTTP workflow

Requesting auth mechanisms/providers: C -> S GET owncloud/auth/test C <- S 401 (+ list of providers) C -> S POST owncloud/auth/provider (+ provider id?) C <- S 200 URL + temp token

Login in external browser: C -> ID GET identityprovider/login C <- ID 200 login form C -> ID POST idendityprovider/login C <- ID 302/303 owncloud/auth/auth/finish

Meanwhile, polling the server: C -> S GET owncloud/auth/status?token=xxx C <- C 200 status, either 'pending' or 'finished' + new device token

Issues

The identity provider is only asked once, hence killing a session with that provider will not log the client out.

ref https://github.com/owncloud/client/issues/4798

cc @danimo @PVince81 @DeepDiver1975 @MTRichards @butonic @LukasReschke @owncloud/desktop-developers @owncloud/android-developers @owncloud/ios-developers

PVince81 commented 8 years ago

I think the client doesn't need to know about how the web UI logs itself in, it doesn't interest the client.

Basically there are only two authentication methods:

basic auth (legacy)
token-based auth using browser login

In the case of browser login, the client connects to the server and the server returns a constant URL, for example "https://host/owncloud/loginsuccess". This page itself requires log in, so opening it as an unauthenticated user will automatically trigger the existing authentication mechanism (SSO, 2-factor, whichever). This already exists and doesn't need additional work and doesn't require the client to know that there's SSO or 2-factor. Then, as soon as the user is authorized to open the "loginsucess" page, that page internally creates the real auth token and makes it available through the polling endpoint.

In some cases, the user already has an authenticated browser of the same type, so opening the URL "loginsuccess" will directly generate the token without requiring additional login.

rullzer commented 8 years ago

I would even go a step further and force clients to use the weblogin method. That way only tokens are used to secure our users. And since it is all async without real user involement those tokens can be huge by default :)

Now of course the client will need to support basic auth for quite some time still (since we support older servers). But a simple check against status.php could disable basic auth by definition.

We want users to use tokens by default so don't give them a choice ;)

guruz commented 8 years ago

@rullzer In general I agree, but then how can people easily use curl, davfs, file managers etc?

ChristophWurst commented 8 years ago

@guruz you can use the generated token as password, so basic auth user:token works.

rullzer commented 8 years ago

Exactly they have to generate device tokens on the webinterface...

ChristophWurst commented 8 years ago

This seems to be the workflow we aim for: https://en.wikipedia.org/wiki/OAuth#OpenID_vs._pseudo-authentication_using_OAuth

rperezb commented 8 years ago

@davivel your input is appreciated here

ChristophWurst commented 8 years ago

Authentication mechanism detection

With multiple authentication mechanisms available, clients need to know which one is used to either prompt for for login credentials or open an URL in an external browser.

Auth

These are the auth mechanisms we support:

Auth1: old auth with basic auth (username, password)
Auth2: token basic auth (username, token)
Auth3: pure token auth where token is sent as HTTP header. Not yet supported on DAV

Token generation

These are the token generation mechanisms we support:

Token1: user generates token on personal settings page
Token2: send POST request to /token/generate with loginname+password and get a new device token
Token3: use browser-based authentication in external browser #24835 where the client shows a browser with a URL returned by the server

Possible setups/configuration

These are the setups that we need to support:

password auth allowed, 2FA disabled
- Auth1
- Auth2 and Token1
- Auth2 and Token2
- Auth2 and Token3
password auth not allowed, 2FA disabled
- Auth2 and Token1
- Auth2 and Token2
- Auth2 and Token3
2FA enabled
- Auth2 and Token1
- Auth2 and Token2
- Auth2 and Token3
external identity provider used (via apache auth, e.g. shibboleth)
- Auth2 and Token3

Client detection

We need to find a way for clients to detect which auth mechanisms and token generation mechanisms are supported. As discussed with @PVince81 we think that a special info route could be used to return that info. E.g. the client sends a request to /auth/info and gets a list of auth mechanisms and/or token generation mechanisms it can choose from. That route must be accessible without user credentials.

ChristophWurst commented 8 years ago

@danimo @davivel @PVince81 @DeepDiver1975 ^

davivel commented 8 years ago

Thinking in mobile (Android biased):

Step 3a. Open browser window for user and let her/him authenticate

That means OC app goes to background. Easy.

Step 3b. Polling the auth state from the server

Polling in mobile is not generally a good idea, but this is supposed to finish soon, so we could leave an async job or a service in background polling the endpoint for a limited time. It detects the log-in is completed. And then, what we do?

The user just logged into ownCloud, and expects the next window to appear is in the ownCloud app.

Options:

1. Bring the app to the front from the Service. We've never done this before. Fast googling -> seems possible (http://stackoverflow.com/questions/3606596/android-start-activity-from-service), though I'm surprised about it, seems a potentially annoying flow and mobile frameworks tend to forbid this kind of things. I wouldn't put all the eggs in this basket until we test it. And I have no idea if this is possible in iOS.
1. Show a notification to the user, she clicks on it to enter the app. Sure it works, lame UX.
1. Don't open a new browser at all, keep the auth in a Webview where we can monitor the URLs browsed, and dismiss the Webview when redirection to endpoint 3 is detected. Exactly what we do now with Shibboleth.
4. Extending the proposal in the point 3a: after successfully updating the server database, a new redirection is responded leading to a URL with a custom scheme, such as owncloud://host/success. We know from a past experience with an OAuth prospect that mobile apps may be subscribed to handle custom schemes. This would work as an event to bring the app to foreground again, and we wouldn't need to poll anything in background.

Of course, my favorite option is 3, since minimizes the changes needed in the mobile apps. I also like 4, but I don't know if would work fine in desktop (though Safari does it with iTunes).

ChristophWurst commented 8 years ago

@davivel thanks for your input. Personally, I think that option 3 would work best as you have full control over the browser window. Especially closing it as soon as you detect the successful login process is finished will enhance the UX. See https://github.com/owncloud/core/pull/24835#issuecomment-221549525 for a detailed test of what is already possible with my PR. Would 4. be necessary at all if the polling tells you whether the login process was finished or not? Seems redundant.

davivel commented 8 years ago

Would 4. be necessary at all if the polling tells you whether the login process was finished or not? Seems redundant.

No, it's designed specifically so that we don't need to poll. It's intent is being an alternative to implement the polling.

But polling is not needed either in alternative 3, and you wouldn't have to change step 3a.

ChristophWurst commented 8 years ago

Okay, makes sense. However, that would be specific to mobile. That means we'd have to provide two different redirect URLs depending on the client platform.

davivel commented 8 years ago

About the authentication mechanism detection, using a specific path to get the list is OK to me, though I'm not sure from your description what would be the list of responses. The setups with 2FA enabled or disabled include the same combinations in https://github.com/owncloud/core/issues/24794#issuecomment-222933509, how will the client distinguish one setup of other?

Related to authentication detection: what will the server respond to a non-authenticated request on a DAV resource? A 401 response must include an authentication challenge, what would be the content of this if the server does not allow basic authentication?

davivel commented 8 years ago

how will the client distinguish one setup of other?

Self-respond, I guess that should be transparent for the client.

So, the response to GET /auth/info should be a list of valid combinations of authX + tokenY, right?

ChristophWurst commented 8 years ago

@davivel exactly

ChristophWurst commented 8 years ago

Related to authentication detection: what will the server respond to a non-authenticated request on a DAV resource? A 401 response must include an authentication challenge, what would be the content of this if the server does not allow basic authentication?

We need to find a solution for that, too. The fact that we support two different types of basic auth (password or token) might complicate this.

davivel commented 8 years ago

I guess that basic auth with password should keep the "Basic" word for itself, and we should define a specific value for basic with token.

I relate this to auth detection because that's what we do now to find out the auth method, make an unauthenticated request to the root folder and check the response. What makes me think in Shibboleth: the plan is integrating it with Auth3?

ChristophWurst commented 8 years ago

@davivel that is not yet possible, see https://github.com/owncloud/core/issues/24763

davivel commented 8 years ago

Seen, I guess that differentiate it is against the intention of using it as a transparent legacy solution.

Any thought about my other question? Is the plan integrate Shibboleth in Auth3? Right now the detection of Shibboleth as the method to authenticate is based in catching a 302 response with certain keywords when accessing the root folder with an unauthenticated request. If we don't integrate Shibboleth in the scheme of available auth methods, we'll need different detection paths in the client side.

ChristophWurst commented 8 years ago

Yes, the plan is to use the async client login process for shibboleth, where the user logs in on an external browser and the client gets a new token after the successful login process. https://github.com/owncloud/core/pull/24835#issuecomment-221597494 does exactly that, but was postponed to 9.2.

At least how I understood it, Client auth detection should replace that redirect/shib detection clients currently do.

PVince81 commented 7 years ago

I think this is obsoleted by OAuth2 ?