Description
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:
/loginenter 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/pwdfor the default password based auth/login/samlfor saml based auth/login/mailfor sending an email to the user with a login link/login/totpfor RFC6238: A Time-Based One-Time Password Algorithm/login/hotpfor RFC4226: An HMAC-Based One-Time Password Algorithm/login/tiqrfor tiqr based auth/login/smsfor an sms to the users phone, yes it is insecure but still better than no second factor/login/kerbto require a kerberos token/login/certto 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/[email protected] 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.
Related
- WebDAV uses device specific passwords or OAuth. Web UI uses the session.
- Disable user passwords for WebDAV access, enforce device tokens?
- make user_shibboleth become a factor provider. It is not really a user backend.
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\IProvidesEMailBackendand 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