- Write queries should fail if they do not match schema constraints on the Resource DB. We have various layers of permissions for which users can do what actions with specific resources.
Schema constraints are fine, but for a multi-tenant architecture, at some level, you're going to have some form of "tenant id" that needs set as an attribute. At the moment, beyond having N flavors of a similar query with the tenant ID baked into the resource configuration, and then using group permissions to allow access to each, I don't see an easy way to simply specify the "tenant id" dynamically while ensuring spoof-proof security. At one level, you can set it as a user-attribute at the user-level, but when you start looking at users who should have access to multiple tenants, that breaks down quickly. To my first point about having "N flavors" that also quickly becomes a nightmare from a management standpoint, with needing to conditionally choose the correct resource to use based on the user.
- If 1 does not work, they can set up custom auth, or use the auth tokens from a successful auth in an API request to have another service work as middleware on top of the Resource/DB
This essentially requires 1) the user to log into the Retool application then 2) authenticate with a secondary identity/auth provider to get an auth token for use with a middleware, which isn't a great experience. In theory, if this were to work, we can store the 'token' to localStorage and just reference it in REST resources and the middleware can do what it needs to for authorization. I guess it could alternatively be a 'public' app but have the custom authentication take place for the resources, but that seems like it may not be allowed per the ToS.
- Can use OIDC for user login with ent. Not sure if we can do user-scoped but you can add users to groups and have group scoped permissions.
As far as I can tell, the user groups/permissions seems to be only constrained to API calls made to the Retool service layer, there's no way to extend this to a custom middleware.
[UPDATE] Looking at the SSO documentation here Configure SSO with OIDC authentication | Retool Docs, it sounds like what I initially asked in (3) is supported. That said, it would negate much of the benefit of using Retool's abstractions for data source connectors and connecting components "directly" to your data.
Let me know if you have more details about the server-side validation you are looking for, are you thinking data type enforcement? Or more so related to scopes as in which tables/DBs/rows or cols that are specifically being modified?
I think at a fundamental level (correct me if I'm wrong), Retool acts as a data source abstraction layer with a low-code, drag-drop frontend builder. That is, it's providing a nice interface for your underlying data stores. While there are use-cases where your end-user can be trusted within the bounds of user permissions and groups, there are also use-cases, especially with external apps/portals which are being marketed, that some level of server-side input validation is a necessity.
The validation is more to ensure that whatever data is being written is actually a valid or acceptable state for the user write. For example, at a very basic level, I would like to be able to just have a simple validation on if the "tenant id" being written for a new record is something that's allowed by the user (see example snippet below). A more complex case might be to ensure that a user hasn't bypassed client-side validation rules to write invalid data (e.g., from the example you linked for the patient portal, the user isn't able to spoof a value to get a larger quantity of medication than they're actually allowed).
function validateInput(data) { //Where data is the incoming object to write to the resource
if (!current_user.metadata.tenants.includes(data.tenant_id)) {
throw new Error('User is not allowed to write to this tenant.');
}
}