Current implementation assumes that Owner of the container wants to create Top Level Folders with their own ACL as the Owner. This is a deviation from original implementation.
Makes more sense to allow the Top Level Folders to have other users added/removed in the ACL directly from the web interface.
Challenges:
[x] Searching or Validating user list?
[x] Handle multiple users?
[x] Need to add remove logic to remove ACL
[x] Add Environment variable for a global group to add to the container root ACL instead of individuals
Approach:
There needs to be a balance between accessing the DataLake as a superuser and as the actual user. The application is running as the superuser with RBAC. To calculate if a user has access to a container/folder, the application could evaluate each ACL and determine if the user is listed, but that is simplistic especially when using a group. The calculation to determine group membership would be computationally expensive.
A better approach is to use the built in capabilities of the storage account API. If the user queries the storage account under the right permissions, a list of containers/folders will be returned. If the user is only specified in the ACL, the application will still need to use the superuser to get some information, but then can switch to an on-behalf-of flow to query for the specific folders.
Have the application query the storage account for the file systems. This will return more filesystems than the user has access to then query for the top level folders under the User's context.
In order for the user to have access to the top level folders list, they will require ACL r-x at the root of the container. If the app lists the top level folders for the user at the container level and results return, they have access to the container. This will be true regardless of if they are in RBAC or an ACL group assignment, and not just a user assignment. This will also resolve the guest membership issues.
Changes:
[x] Create a second App Registration for the API. This will allow the OBO flow. Link the app registrations using the knownClientApplications.
[x] Change the staticwebapp.config.json to use the older v1 auto where the resource=api://{guid of api app reg}
[x] Refactor the TopLevelFolderOperations to only operate on files and not access other "operations" that require a "different" context. (ex, ask the Roles which operate as the superuser).
[x] Remove the ACL access calculation (keep the ACL query for display)
[x] Change the FileSystem logic to get a list of all FileSystems for an account.
[x] Change context to user, check each filesystem to see if the user can "GetPaths". If the user can get Any path, add the filesystem to the list of accessible ones.
[x] On a new folder creation, add use "r-x" on the root folder for the user/group added.
[x] Add TopLevelFolderOperations method that allows the change of ACL based on user/group list. The change should compare against existing ACL on the folder and root and reconcile differences to make them match.
[x] On the folder list method, change the folder list to operate under the user context. if the user has "r-x" all top level folders will be listed. The method will then need to "try" each folder for a GetPaths operation to determine if the user has access to the folder. This will work for all users with the same logic.
[x] Sacrifice an approriate offering to the Developer gods
Current implementation assumes that Owner of the container wants to create Top Level Folders with their own ACL as the Owner. This is a deviation from original implementation.
Makes more sense to allow the Top Level Folders to have other users added/removed in the ACL directly from the web interface.
Challenges:
Approach: There needs to be a balance between accessing the DataLake as a superuser and as the actual user. The application is running as the superuser with RBAC. To calculate if a user has access to a container/folder, the application could evaluate each ACL and determine if the user is listed, but that is simplistic especially when using a group. The calculation to determine group membership would be computationally expensive.
A better approach is to use the built in capabilities of the storage account API. If the user queries the storage account under the right permissions, a list of containers/folders will be returned. If the user is only specified in the ACL, the application will still need to use the superuser to get some information, but then can switch to an on-behalf-of flow to query for the specific folders.
Have the application query the storage account for the file systems. This will return more filesystems than the user has access to then query for the top level folders under the User's context.
In order for the user to have access to the top level folders list, they will require ACL r-x at the root of the container. If the app lists the top level folders for the user at the container level and results return, they have access to the container. This will be true regardless of if they are in RBAC or an ACL group assignment, and not just a user assignment. This will also resolve the guest membership issues.
Changes: