"Something went wrong" warning on login with no roles is too generic

[twinfees]

Users logging into a silo for the first time can be met with a generic "something went wrong" warning, which seems to be the defacto warning for misconfigured role assignment.

Opening this issue to request a more clear warning to the user to prevent confusion if they're not yet authorized (i.e. user not added to the group that was assigned to the silo admin group, etc).

[morlandi7]

notes from 1/27 prod eng mtg - Use case is user is logged in. We debugged this by checking the roles page in settings. This is hit often. Is there more active direction we can give. Ex we received. customer hit this when creating silo and hadn't done so in a while.

[askfongjojo]

I've put in a reproducible case on dogfood for a Keycloak user:
Login URL: https://silo11.sys.rack2.eng.oxide.computer
Login: sorry
Password: somethingwrong

[david-crespo]

Thank you, that's perfect. I think we can detect this condition by looking at whether the following are both true:

1. Current user has no groups
2. Current user is not given a role directly in the silo policy

1 alone is not sufficient because a user could be assigned a role directly despite not being in any groups. Nobody does that, though, so 2 will almost always be true.

Rather than linking to some settings page, I think in this situation we should just show a message on the error page to the effect of:

You are not in any groups and you have no assigned role on the silo. This is usually due to a misconfiguration of the admin group name on the silo. Contact your administrator.

Investigation

I can confirm the group list is empty and it is the project list call that's 403ing (the /v1/system/policy 403 is expected — we use it to test whether the user is a fleet viewer and eat the error).

As the bad user I can also hit the silo access page, which uses the endpoints for silo policy, users, groups. Silo policy makes sense, but I'm a little surprised that we can list users and groups given that we can't list projects.

[david-crespo]

I wanted to confirm what permissions each of those API calls is looking for. Project list is the only one in this list that the user with no groups or silo role fails. The others work because the permissions required are granted as part of silo read to all users in a silo.

• project_list wants ListChildren on silo (as expected) (source)
• listing users for silo requires ListChildren on silo user list resource (source)
  • anyone who can read the silo has that perm (source)
  • silo group list just checkes silo read directly instead of going through the user list authz resource, which is wrong in theory but right in practice (source). I'll make a note to fix this check.
• current silo policy uses ReadPolicy action (source), which just maps to the Read perm (source)