Users fail to login after enabling candid/rbac if they existed before
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Triaged
|
Low
|
Unassigned |
Bug Description
When you enable Candid/RBAC external authentication in maas, some users will fail to be able to login if another user with the same name existed before in the local database.
If you deploy MAAS and go straight to enabling rbac, everything works fine, all users work normally.
But if you first enable local authentication, create users locally, and later switch authentication mode to rbac, users in candid with the same name as previously existing users will fail to login in maas.
Maas will say "user not allowed" as if the user had no roles defined in rbac, even if the user does exist and has the roles set (does not matter if admin role or user role).
It is specially frustrating when you have a local user called "admin" and later move to rbac, trying to keep your account name. It's like maas does not clean everything during the switch. If this is a feature (intentional), it is not clearly documented and certainly not meeting normal expectations.
Note: this is valid for static users (with no domain) in candid. I have not tested but I imagine that users with a domain (user@domainname) will not suffer from this since they are always different by definition.
Changed in maas: | |
status: | New → Confirmed |
Changed in maas: | |
milestone: | none → 3.5.0 |
importance: | Undecided → Medium |
Changed in maas: | |
importance: | Medium → Low |
I can confirm this behavior. It's not restricted to the user "admin" either, any users who previously registered with "normal" maas auth will not be able to also register with Candid. I'm guessing the behavior works in reverse, although I haven't tested it yet.
See this attached log for a MAAS error message complaining about non-unique pks:
https:/ /pastebin. ubuntu. com/p/MbsHCKFCx 7/
This seems to be a MAAS specific issue -- As Candid/ canonical- rbac report a successful authentication.
To me, the correct behavior should be to remove any "old" auth methods after setting configauth in MAAS. Perhaps they can be backed up, but I think it would be reasonable to purge them entirely.