[WIP] Rework authentication code

butonic commented 6 years ago

In deployments that allow passwerd/ldap based login and SSO via SAML we currently recommend to set up oc with password based login under /owncloud and SAML protected login under /oc-shib. That is bullshit because links generated when accessing the site via saml will contain the /oc-shib part, which prevents access to the share link without going through SAML. Setting overwrite.cli.url does not fix that (and is not intended for that).

I would be great to expose different factors under different urls, eg:

/login enter only the login name. oc can then decide which factor will be used to authenticate. the admin may dafine an auth chain or tha user may add a factors. That is deployment specific
/login/pwd for the default password based auth
/login/saml for saml based auth
/login/mail for sending an email to the user with a login link
/login/totp for RFC6238: A Time-Based One-Time Password Algorithm
/login/hotp for RFC4226: An HMAC-Based One-Time Password Algorithm
/login/tiqr for tiqr based auth
/login/sms for an sms to the users phone, yes it is insecure but still better than no second factor
/login/kerb to require a kerberos token
/login/cert to require a client certificate ...

We could extend the existing OCP\Authentication\TwoFactorAuth\IProvider2, currently using urls like /login/challenge/totp

Instead of checking if twofactor is enabled I propose to look at how pam allows configuring the auth. A login via saml or pwd & sms could be configured like this:

'auth.factors' => [ // order is important ... or we store this inside the db
  'pwd' => 'required',
  'sms' => 'required',
  'saml' => 'sufficient'
],

After entering the login on /login the user will be redirected to /login/challenge/pwd to enter his password, then to /login/challenge/sms to enter a pin that was send via sms. The /login route can detect if a saml session is present and redirect the user to /login/challenge/saml which is a saml protected endpoint. This might even be done by apache to reflect the desired auth behavior (eg saml in the internal network, pwd+sms from outside)

Login via saml or password like this:

'auth.factors' => [
  'pwd' => 'sufficient',
  'saml' => 'sufficient'
],

It should be possible to directly use a url like /login/challenge/pwd?login=alice@example.org to fill in the user without having to go through the login page. This allows other systems like an F5 firewall do preauthenticate users and then directly invoke a certain factor.

Questions

What about autoprovisioning upon first login?

after authentication happened metadata like displayname, email and avatar need to be provisioned on the first login. We already have OCP\User\IProvidesEMailBackend and the like. They can be used to fill in the metadata for new accounts. If any field is missing show a form to the user to enter missing metadata before allowing login?

What about matedata sync?

after authentication happened metadata like displayname, email and avatar need to be updated. If it is available in any of the user_backends it will be used to update the account.

Scenarios

Log in via SAML with autoprovisioning

saml is required. no pwd based auth.

saml token contains email. email is looked up in the account table. corresponding user is logged in.
saml token contains userid. userid is looked up in the account table. corresponding user is logged in.

Log in LDAP user via SAML

saml is sufficient. pwd based auth against ldap possible as well.

saml token contains email. email is looked up in the account table? directly in ldap? corresponding user is logged in. metadata is updated from ldap
saml token contains userid. userid is looked up in ldap. returns a userid. corresponding user is logged in. -> userid lookups should happen directly with ldap to allow login with email, even if it was changed and differs from the account table, so that login and sync is still possible

Log in LDAP user via SAML or autoprovision

saml is sufficient. pwd based auth against ldap possible as well. if no ldap user is found it will be autoprovisioned

saml token contains userid, email and displayname. email is looked up in ldap. returns a userid. corresponding user is logged in. metadata is updated from ldap
saml token contains userid, email and displayname. email is looked up in ldap. not found. is looked up in account table? or directly in saml? corresponding user is logged in. metadata is updated from saml token

Log in user via Facebook or Twitter

'auth.factors' => [
  'facebook' => 'sufficient'
  'twitter' => 'sufficient'
],

show alternate login buttons on /login because no login needs to be entered, really or can that be the fb / twitter login which is then used to prefill the login requests for fb/twitter? might make sense if admin allows login via fb and user opted in to that so he enters his login and then is forwarded to /login/challenges/facebook instead of /login/challenges/pwd if fb fails he is forwarded to the pwd challenge as a fallback. What about the userid that fb / twitter provide. we need to tie that to the account. each factor needs his own mapping to an account. -> an oc_account_auth table with (accountid bigint, factor varchar 10, login varchar 255, lastlogin datetime) with a uniqe index on the first three columns

Log in user via Facebook or Twitter as the second factor

'auth.factors' => [
  'pwd' => 'required',
  'facebook' => 'required?'
  'twitter' => 'required?'
],

Hm noticing that a simple list is not good enough. how should the admin specify that he wants users to use twitter OR facebook OR an email token as a second factor? Present the user with the additional auth sources so he can choose?

Benefits:

Prevents unaccessible share links.
Password based login code could be moved to an app to completely disable it.
Same code for all logins.
Admin configurable auth factors.
Passwordless login possible by eg always using a login token sent via mail
Users can add additional factors

ownclouders commented 6 years ago

GitMate.io thinks the contributor most likely able to help you is @PVince81.

butonic commented 6 years ago

hm. we could solve this for apps like user_shibboleth by making it provide a login endpoint at eg. oc.example.com/apps/user_shibboleth/auth. In the apache config we could then redirect unauthenticated users from the internal network to that endpoint. in addition to https://github.com/owncloud/documentation/blob/918fc44c1dc956d32c5d016f5428521a6a9b0d60/admin_manual/enterprise/user_management/user_auth_shibboleth.rst#apache-configuration we could do a redirect to that endpoint.

cc @dercorn @tomneedham

PVince81 commented 6 years ago

no activity, moving to backlog

we should decide when we want to actively work on this and schedule some time

owncloud / core