flow for unprivileged users

[davepacheco]

Suppose you create a Silo with a real identity provider (IdP). The first time an IdP user logs in, their user is JIT-provisioned in the Silo. If the operator has set things up so that roles are assigned to members of IdP groups, and the user is a member of some groups that have roles, then the user may get some privileges -- great. But if not, the new user has no roles on any resource. Right now, that means they won't see any Organizations, which means they can't see anything else either. Fair enough -- they don't have access to anything.

We talked briefly about saying that unprivileged users in a Silo should have the privileges required to list the Organizations in the Silo. The thinking would be: if you don't trust everyone in the Silo to know about each others' Organizations, well, put them into different Silos. But I realized this isn't enough: now they can see the Organizations, but they can't see the Projects or anything else in the Organizations. That's not much better.

Another thing that sucks here: suppose somebody does share a particular Project with them. None of this changes: they still can't see any Organizations. If they know the name of the Organization and Project, they can navigate to it and all should be fine. But they'd have to type that into the URL bar.

I see a couple of options here:

• The endpoints to list Organizations and Projects could be modified to list any that you have access to. This seems like the obvious answer but it has problems. We explicitly punted this out of the MVP because this requires either richer support from Oso than we currently have (data filtering) or we hand-roll our own (which isn't simple either). It's worse than that: with the current model, you can work with any Organization if you have access to anything inside it. (That is, someone only needs to share a Project with you, and that implicitly grants you access to see the Organization that the Project is in.) That means answering the question of what Organizations you can see is potentially very complicated expensive (e.g., do you have any role on any resource whose parent ['s parent['s parent...]]] is this Organization).
• Lean-in on the other direction: everyone in a Silo can see all the Organizations and all the Projects. That's broader than we were initially thinking, but I come back to the idea that Silos are the unit of isolation, and if you don't want people to see things, they need to be in different Silos.

[davepacheco]

We discussed this in today's RAP/IAM call. Here's what I think we landed on: rather than changing anything about the current behavior, we recommend that customers deploying the rack have an "everyone" group in their IdP that has everybody in it. Then when they set up the Silo, one of the first steps should be to grant the "silo viewer" role to that group. This is blocked on IdP group support, which is in progress.

Concretely, for the demo, this means that both "alice" and "bob" would be in the "everyone" group. When we create the Silo, "alice" will grant the "silo viewer" role to the "everyone" group. This is part of the pre-demo setup. During the demo, bob can log in for the first time and will be able to see everything. (We could also move this assignment to during the demo, showing that "bob" initially has no permissions. But we can't demo that now without an oxide api call -- hence putting that in the pre-demo setup part.)

We considered the alternative of granting all silo users the ability to see all Organizations and Projects in the Silo. This could be evolved in a way that's able to be locked-down and even locked-down by default. In v1, we just say that all users can see all Organizations and Projects. In v2, we could create the idea of built-in groups that includes an "everyone" group. As part of that upgrade, we'd create a role assignment for each existing Organization and Project that grants the "everyone" group the "viewer" role on that resource. We'd also create that role assignment for all new Organizations and Projects. In summary, in v2, the default behavior is the same (everyone can see everything), but individual Organizations and Projects could be restricted. In v3, we could allow configuration at the Silo, Organization, or Project level that says what role assignments are granted by default for new children. (Or we could just require you to specify this when you create any Organization or Project, and just have the console prepopulate "everyone is a viewer".)