OAuth users cannot confirm password for sensitive actions (Administration, settings, etc.)

[tuzumkuru]

Hi,

Thanks for developing and maintaining this plugin. I love using this plugin and making Google OAuth a SSO option for Redmine. I have a problem though:

When using this plugin, login works fine. However, after some time in the session, if I try to change settings Redmine asks for a password confirmation. Since OAuth users don’t have a local password, they cannot continue. This is also a problem if I use sudo_mode. Some time after login, if I want to act as an administrator, it asks password but no option go authenticate through OAuth.

Steps to reproduce:

• Log in to Redmine using OAuth.
• Wait some time after login (session idle period).
• Try to change a setting.
• Redmine asks for password confirmation.

OAuth user cannot proceed (no local password).

Expected behavior:
OAuth users should be able to bypass or satisfy password confirmation without needing a local password.

I believe this would be a necessary feature/fix for this plugin. Otherwise what would you suggest?

[picman]

Do you use other plugins? I think that pure Redmine just redirects you to the login page when the session expires.

[tuzumkuru]

Hi Karel,

When the session expires, you are right, it redirects to the login page.

I am using sudo_mode in which you set a timeout for Redmine to ask for a password when timeout expires for security important tasks, ie. Account or Administrative changes. It doesn't redirect to the login page, instead ask the password at the same page.

Below is a SS from a local instance when I try to change a setting in my account page after the timeout period. This local instance only runs a plugin which i am working on but irrelevant to the issue. sudo_mode is set to true to show this behaviour:

About sudo_mode:

 # Requires users to re-enter their password for sensitive actions (editing
  # of account data, project memberships, application settings, user, group,
  # role, auth source management and project deletion). Disabled by default.
  # Timeout is set in minutes.
  #
  #sudo_mode: true
  #sudo_mode_timeout: 15

from https://svn.redmine.org/redmine/tags/5.1.0/config/configuration.yml.example

[picman]

Thank for the explanation. Now, I know what you are talking about.

A possible solution would be to add a button "Continue with OAuth" next to the Submit button which would authenticate the user with the configured OAuth provider.

A problem is that there are no hooks on Redmine's side to allow plugins to extent the present functionality. So' I'd have to override the view and the controller as well.

In our environment we also use OAuth but we also heavily use the integrated SVN and git repositories and also WebDAV. To authenticate to these modules users must keep their passwords. OAuth just makes easier to log into the web interface.

[tuzumkuru]

I am trying to avoid password use since logging in Google is more secure since it needs 2FA and I don't want users to set 2FA in redmine too or everywhere for their convenience. I am trying to provide a real SSO experience.

My workaround is asking them to logout and login again and then do the change before sudo timeout. I use my password with 2FA with administrative tasks though.

I think there should be a fix to make redmine's login system controlled from one place and providing hooks to add methods there. That would be the most elegant solution. I don't know rails so can't comment more.

You can close this issue if you want, or keep it open until there is some solution. Overriding the view and the controller might be a good fix but i guess it is risky for future updates?

[jirutka]

I’ve solved this in my redmine_oidc, see this commit. It doesn’t work perfectly, but you can take it as an inspiration.

[picman]

Thinking about that again...
The principle is in that that if a user leaves their browser opened and somebody else comes to the computer, certain actions are protected by "sudo mode". It means that the user is asked to re-enter their password before such an action is triggered. It makes a perfect sense if we use login and password. But, in case of OAuth, what does happen? We just ask the OAuth provider for authentication and because the user has already been authenticated, OAuth just answers OK. Where is the added value from security point of view? From this perspective it seems to me that the "sudo mode" should just be disabled in the configuration.

[jirutka]

That’s not quite right. OAuth/OIDC supports forced re-authentication, e.g. with prompt=login or max_age=0, so sudo mode can still add security by requiring the provider to re-check the user instead of silently accepting the existing browser session. This is what I implemented in my redmine_oidc plugin; see the comment above. Disabling sudo mode globally would also weaken protection for local-password users. The better fix is to make sudo-mode confirmation compatible with OAuth users, not to disable it.

[picman]

I've more or less copied your solution. Thank you for the hint. Could somebody test it in the devel branch and provide a feedback?