Discussion: Status after oauth user deactivation

[col-panic]

If a user is added through Oauth, or merges to oauth login and is subsequently deactivated in the central IdP this deactivation does not propagate to Redmine.

Imagine this case:

1) User exists in Redmine 2) Admin migrates to oauth login (by tightening password rules that much, its uncomfortable to login using password) 3) User gets centrally deactivated in the Oauth provider 4) User still is able to change its password and login to redmine

I don't know what a proper solution would be to propagate the deactivation of the user to redmine, and its interesting for other SSO services too. You would expect, that by centrally disabling a user it becomes inactive on all connected services, or wouldn't you?

[col-panic]

It seems there exists a specification for a user synchronization in https://scim.cloud/

It would however be already of advantage, if we could FORCE users to use oauth2 login only. Lets say, users have to use oauth2 login. This plugin could feature a ruby script that enables/disables this feature.

Lets say I execute

• ruby lockdown on the system as script - now login is generally only possible via oauth2
• ruby release on the system as script - both login paths are open again

[tuzumkuru]

If i get it correctly, I support this issue too.

Maybe there could be some sort of login type restriction for users implemented, so that oauth users (the users created with oauth or merged and logged in with oauth) are restricted from logging in with the password. i can't think of how it can be imlemented for now.