-
Notifications
You must be signed in to change notification settings - Fork 47
Description
Recent conversations have been asking whether a user from silo A would have any reason to look at users or resources in silo B. While general sentiment is that cross-silo access to resources (instances, VPCs, etc) can be omitted for v1, users isn't quite so clear.
At a minimum, we need to handle the initial setup case. Assume a fresh rack where RSS has created an initial silo R that uses local authentication only and has a single user provisioned, user R_admin (_ notation for clarity and conciseness). User R_admin is granted CRUD permissions on silos themselves with the intent that this silo is primarily used for initial setup and recovery purposes. User R_admin creates a new silo, A, with an IdP configuration to allow login via SSO and JIT account provisioning. At this point silo A contains no user accounts as no logins via SSO have occurred. So how does user R_admin designate a user in silo A as a Silo Administrator?
One option is to have someone login to silo A via SSO which causes their account to be created as user A_user1. User R_admin can now see that account when the list the user accounts in silo A (note the cross-silo access here). R_admin can now assign the Silo Administrator role to A_user1. This has a few disadvantages:
- Users with Silo CRUD permissions are implicitly given access to at least list users and modify ACLs in all silos
- If R_admin != A_user1, the process need to be passed back and forth between them
- If A_user1 accidentally removes their Silo Admin role, only R_admin can recover it
- Every role assignment would need to be made individually after each user has logged in
Alternatively, Silo configuration could specify a SAML assertion key that contains group membership provided by the IdP as well as a mapping of group identifiers to role assignments that define "default" role assignments. For example, a SAML assertion might say user B_user1 is part of IdP groups B_IDP_DOMAIN_ADMINS and B_IDP_IT while silo B's configuration says B_IDP_DOMAIN_ADMINS grants Silo Administrator and B_IDP_ENGINEERING grants Collaborator. This can all be set up before any users log into silo B. When a user does login to silo B via SSO, Nexus would extract the groups from the SAML assertion, translate them to roles, and apply those roles to the user. Since this happens on each login, even if B_user1 removes their Silo Administrator role by accident, logging out and back in would restore it.