want way to define initial silo policy

[augustuswm]

Currently when initializing a silo, a user can define the admin_group_name property for a group coming from an associated IdP. A user in that group then needs to authenticate against the new silo and perform the remaining policy mappings. When these are separate users, this can be a good separation of responsibilities.

When this separation is not needed, we end up introducing additional friction for silo creation. Having a way to provide a generalized mapping of group names to silo roles would allow for both of these steps to be collapsed into a single call. Something along the lines of:

"group_roles": {
  "idp-admin": "admin",
  "idp-writer1": "collaborator",
  "idp-writer2": "collaborator",
  "idp-viewer": "viewer",
}

Happy to submit or discuss this in RFD form as well.

[davepacheco]

Part of the reason we didn't go with this approach originally is that there's no way for us to validate the group identifiers that they give us. It would be pretty easy for someone to put the wrong thing here (hyphens instead of underscores, say). Then we'll wind up having created some groups locally that don't exist in the IdP. And we won't grant the privileges they expect to the users that they expect.

[augustuswm]

I think that definitely makes sense from the perspective of creating the wrong groups during silo create. I'm not sure how we would be able to validate groups against an external IdP (i.e. the realm may not even exist at that point).

I do think it makes the creation / onboarding experience odd. Essentially we can't define permissions for a given group of users until they have actually authenticated. For our use case, where we are able to define the IdP realm as needed, this isn't too bad as I assign all of the needed groups to the single admin user. But it would certainly be more problematic without that level of control.

Setting aside for a moment the ability to validate a configuration at silo create time, we could certainly avoid provisioning non-existent groups by deferring group creation to user JIT time. The time at which a group is JIT'd then would be the point at which it is assigned to the silo IAM policy. This doesn't stop changes in the IdP from causing group desync, but we could prevent misspelled group names from being created.

Writing this out, this kind of mapping sounds like something that is more appropriately a property of the IdP resource creation (on the rack) than a silo.

[davepacheco]

Yeah, we could definitely do something like this.

I think we're getting at some common limitations of JIT-provisioning and I wonder if we might also revisit better IdP integration options. SCIM and even LDAP in principle could enable a much smoother process here because we could validate groups or even autocomplete them, etc. When we last looked at this (around RFD 234), there was a large space of choices here and no obvious consolidation among prospective customers, which made it hard to decide how to focus efforts. But I feel like if we really want to improve this, maybe it's worth looking again at those?

[augustuswm]

That makes sense to me. I can start a PR discussion against 234 for some of the options of expanding what we have (including looking at what other vendors are doing).

[davepacheco]

Sure. I think it would be especially useful to get customer/prospect input, since a customer really has to buy into whatever we do in this regard, and it's not something I expect we'll have much influence on.

Relatedly, do we have a sense of how big a problem this is for current and prospective customers?

[augustuswm]

Currently this is only internal (from what I know), and we work around it. My expectation though is that as customers start exercising multi-silo administration more, they will run it to it as well.

[askfongjojo]

I believe the current way of working around the constraint (which our customers using IdP might have already figured out) is to have the silo admin as members in all the lower-permission groups (using the example in this issue, the user will have 4 memberships: idp-admin, idp-writer1, idp-writer2, and idp-viewer). Once the silo admin has logged in, all groups get created and can be configured for access before anybody else logs in. The workaround is admittedly rather obscure but has allowed us to prioritize the need for SCIM or LDAP search lower.