Better UI Access Control Mechanism

[t83714]

Better UI Access Control Mechanism

We probably don't want to decide UI access based on user's potential actions on that UI module. Why?

• One UI module might involves many actions and we want to max. reuse the UI so that:
  • some users might not have access to certain action but still be able to access the UI module
  • e.g. "View Users Page". Even a user without update user permission should be able to access this UI module as long as the user can view some users.
• Cost is high (as we need to consult auth decision for all possible actions)
• Inaccurate & "too early to tell"
  • Some auth decision is related to the data supply and can only be determined at the time when the action is performed
  • e.g. update a user
• Hard to reflect the user's true intention.
  • it's possible that we want to hide some UI module event the users have the permission to perform the required (or partial) actions

Alternative Approach / Solution

• Managing access to UI module by accessing URL path
• Allow system to manage the new access items: UI module. It comes with the following attributes:
  • id
  • name
  • URL path
  • description
  • landingWeight
  • an optional number indicate which module should be the default landing module for the current user.
  • the module with highest landingWeight among all modules that the user can access will be the landing module for the user.
  • ownerId
  • createTime
  • creatorId
  • editTime
  • editorId
  • pre-authorised-permissionIds: this list should be managed by a separate table ui_module_permissions with the following field
  • permission id
  • module id
  • createTime
  • creatorId
  • editTime
  • editorId
• We need the following APIs
  • POST /content/ui/modules create a new UI module
  • GET /content/ui/modules list all accessible UI modules.
  • This API will always restrict the access to pre-authorised modules even you have ui/module/read with no constraint
  • why? e.g. Admin users can every modules. but for purpose of menu items generation, we will only want to retrieve the items that specifically assigned to him.
  • GET /content/ui/modules/all list all UI modules that users can access
  • PUT /content/ui/modules/{id} update an UI module
  • DELETE /content/ui/modules/{id} delete an UI module. You can't delete an UI module when there is still records attached to it.
  • POST /content/ui/modules/{id}/role/{roleId} Assign a UI module to a role
  • A ad-hoc auto-permission will be created with operation url: ui/module/read & pre-authorised constraint
  • a relevant record will be added to the ui_module_permissions table
  • The created permission will be assigned to the selected role
  • DELETE /content/ui/modules/{id}/role/{roleId} Remove a UI module from a role
  • a list all permissions of the role with uri: "ui/module/read" & pre-authorised constraint
  • Any permission with matching ui module id can be found from ui_module_permissions will be deleted from ui_module_permissions
  • the permission record will be deleted as well
• upon login, the UI should request GET /content/ui/modules endpoint to retrieve a list of permitted modules
• How to determine the default landing URI for a user?
  • Each UI module record comes with a landingWeight with default value 0
  • System will pick the item with highest value of this field as the default landing URL / UI module