Simplify logic for revealing Tenants that a Principal has access to

[Snarr]

Currently, revealing the Tenants that a Principal has access to requires parsing through the Principal object and conditionally performing an additional RPC request. This issue documents that complex flow and proposes possible solutions to simplify the user experience.

Current Flow

1. Perform RPC WhoAmI or RPC GetPrincipal request
2. Parse through the Principal object returned:
3. If Principal has GLOBAL_ACLS to perform READ action over TENANT resource: (3.5): Perform RPC SearchTenant request and use all TenantIds returned in request
4. Else if Principal has PER_TENANT_ACLS: (4.5): Parse through the keys of the PER_TENANT_ACLS in the object and use the TenantIds returned in request

Alternatives

If LittleHorse users find themselves implementing this flow very often, we should be considerate and supply an out-of-the-box solution as an alternative to this complex flow.

Here are some alternative ideas:

1. Add an RPC ListTenantsForPrincipal

We add an RPC that takes in a PrincipalId and returns a list of TenantIds. The server handles all of this logic internally for discovering what Tenants a Principal has access to.

Pros:

• Reduces the flow from 6 steps to 2 steps on the client's side
• Reduces the number of RPC calls being made to the server, as the server can handle step 4 internally

Cons:

• Replaces a client-side solution with a server-side solution, adding complexity to the server and another RPC that we would need to maintain

This could be reduced to 1 step if the RPC behaves as RPC ListTenantsForCurrentPrincipal and infers Principal similar to RPC Whoami

2. Add an SDK method ListTenantsForPrincipal

We add an SDK method to each of our SDK libraries that takes in a PrincipalId and returns a list of TenantIds. The SDK method bundles the same steps listed above into a single method, abstracting away the messy flow.

New Flow:

1. Call ListTenantsForPrincipal(principalId) method

Pros:

• Reduces the flow from 6 steps to 1 step in the user's codebase
• Does not increase complexity on the server side

Cons:

• Still uses two RPC calls
• Adds complexity for maintainers of the SDKs, as the same logic would be written across many different codebases. Much more room for error.

3. Change the implementation of RPC SearchTenant

Currently, RPC SearchTenant can only be called by Principals with GLOBAL_ACLS to perform theREAD action over the TENANT resource (or higher permissions).

This solution proposes that we refactor RPC SearchTenant to be used by any Principal that wants to know what Tenants it has access to.

Principals would perform an RPC SearchTenant request and the server would return all of the Tenants that Principal has permissions over.

Pros:

• Most intuitive functionality for users
• Does not add any RPCs or SDK methods

Cons:

• Changes our entire policy for restricting Cluster-Scoped Resource access to admin Principals
• Adds complexity to the server by requiring Tenants to be filtered by Principal

[HazimAr]

This is going to be required for the dashboard to have 100% accurate info on which tenants the principal has access to.

[Snarr]

@HazimAr can the dashboard not follow the current 6-step flow outlined above? Or would that flow not respond back with accurate info? Curious to hear more about how this current flow affects the dashboard, because that may make this issue go from low to high priority.