add API for listing silo users

[davepacheco]

Fixes #1235.

This change:

• renames the existing /users (which lists built-in users) to /users_builtin.
• creates a new /users that lists Silo Users. These objects only have a uuid in them right now. They could eventually have external_id but I think that will depend on Support for SAML as a Silo IdP, part 2 #1210. Presumably we eventually want them to have display names too, but that too depends on figuring out if/how we get this as part of the SAML login. (Since other systems do JIT with SAML and presumably also want to include display names, I'm guessing some SAML IdPs provide this using a mechanism similar to what they do for groups, but I don't really know.)

CC @david-crespo I'm not sure if this change will wind up breaking the console flow you have because there's only an "id" now.

[davepacheco]

This is ready for review but I'm leaving this as a draft because it depends on #1265.

[davepacheco]

There's one issue I need to fix: currently, only privileged users can list Silo users. I imagine we'll want to make all users able to list users.

[david-crespo]

There's one issue I need to fix: currently, only privileged users can list Silo users. I imagine we'll want to make all users able to list users.

Not sure. Any authenticated user? Feels wrong, but I can't think of a good reason why. Are you thinking because anyone can create a project, and therefore be an admin on that project, and then they have to list user to assign roles? Can anyone create a project?

[davepacheco]

It's possible today to have (useful) users that cannot create Projects. They could potentially have full control over Projects that were shared with them.

But I feel like "name" and "id" information about all users in the same Silo is both reasonable and probably expected. Without this, you couldn't even see who else has access to the same thing that you have access to.

[david-crespo]

Without this, you couldn't even see who else has access to the same thing that you have access to.

Yeah, that makes sense. Wasn't sure whether this is expected. In the GitHub web UI I can't see this on a private repo for which I'm not an admin because they block access to the whole settings view. But it turns out you can still get the list of collaborators from the API:

gh api /repos/oxidecomputer/<repo>/collaborators | jq '.[] | { login, permissions }'

I wonder if there's a distinction to be made between listing users on a particular resource and enumerating all users?

[davepacheco]

I wonder if there's a distinction to be made between listing users on a particular resource and enumerating all users?

It's possible but tricky. I imagine we'll eventually add a /users/$uuid endpoint for looking up a specific user. It's not really feasible for that to check whether you and the requested user share any resources in common. We could provide that information when you list the policy (and not if you request the same user explicitly). It'd be a little inconsistent but maybe pragmatic.

It seems surprising to me that people would want to put two people in the same Silo that couldn't know about each other. Wouldn't you use different Silos for that? But if we're not sure, we can raise this with product.

[david-crespo]

I was picturing something more at the endpoint level, like you can't get anything out of /users unless you have the right permissions, and then on the /<resource>/policy endpoint the check is simply whether you have read access to the resource. But I agree that it adds a lot of complication for dubious value. Listing users if you are in the silo seems reasonable. We can think about restricting it later if it comes up.

[davepacheco]

Okay, this version lets all users see all users in their own Silo. I added this endpoint to the allowlist of things without authz test coverage because the test doesn't currently support endpoints that are totally public for all authenticated users. I will file a new ticket for this though because we have a couple of them now.

Edit: #1277.

[david-crespo]

Very straightforward.