Using DEX, is it possible to create a user and aut...
# gooddata-cn
c
Using DEX, is it possible to create a user and authorize them to 1 workspace only?
r
Not at the moment. But we are implementing a system of permissions that will allow you to grant access to specific workspaces, dashboards etc.
c
Thanks for your reply, @Robert Moucha. Can you suggest any workarounds for doing ACL until that release? Currently all users have global access which is a huge limitation for a production deployment.
r
I'm fully aware of possible consequences. I think there's no reasonable workaround. ACLs or permissions must be checked on many levels so it's virtually impossible to restrict access "from outside".
c
We were wondering if possible workaround to expose the GDCN via proxy which would allow whitelisted resources/actions only.
@Robert Moucha Recommend add this ACL limitation to https://sdk.gooddata.com/gooddata-ui/docs/cloudnative_limitations.html as the consequences are very significant.
Perhaps instead of a proxy whitelist approach, we can do a blacklist approach and blacklist /list and /delete actions.
r
Missing ACLs are docummented in https://www.gooddata.com/developers/cloud-native/doc/1.4/administration/auth/ (see red box). But you're right that it should be mentioned explicitly on some highlights page. I will pass this idea to our documentation team.
I examined the possibility of whitelisting as you propose. Basically you need to allow the following requests that start with
/api
(there's no need to block requests that do not start with
/api
in URI):
Copy code
GET /api/entities/organization
GET /api/entities/admin/organizations/{wsId}
GET /api/layout/workspaces/{wsId}/...
GET /api/entities/workspaces/{wsId}
GET /api/entities/workspaces/{wsId}/...

POST /api/actions/workspaces/{wsId}/execution/afm/execute
POST /api/actions/workspaces/{wsId|/execution/afm/computeValidObjects
GET /api/actions/workspaces/{wsId}/execution/afm/execute/result/...
Three dots at the end of URI mean that all nested resources should be allowed. Note that our apps also call
GET /api/entities/workspaces
that return all workspaces. This call is used for workspace list retrieval used on home page and workspace picker. So this call should be intercepted and its result somehow modified to return only allowed workspace (
wsId
). The list above should be sufficient for "read-only" workspace access. If you want to allow your users to modify workspace elements (create metrics, dashboards and reports), additional methods (POST, PUT, DELETE and PATCH) must be allowed on specific URIs. Please refer to our OpenAPI docs.
c
Thank you, Robert. This is super useful, and will help us workaround until ACL is implemented.
r
Well, no problem. let's hope I didn't forget on some calls but I believe you can easily identify and add missing pieces.