Jetspeed 2
  1. Jetspeed 2
  2. JS2-1100

DeveloperBrowser-type portlets for delegated admin can be used to assign global admin role

    Details

      Description

      There is no way for a deployer to configure preset lists (or combinations) of allowed roles etc that a delegated administrator can assign to filtered users, or to filter out certain roles from the list of options available. (Also no way to set required attributes like language, which would be useful too).

      So a delegated admin can give users full global admin privileges. This makes the portlet unsuitable for production use.

        Issue Links

          Activity

          Hide
          David Sean Taylor added a comment -

          only allow delegated user managers to assign roles and groups in which they already belong
          exception is administrator, who can assign all regardless

          Show
          David Sean Taylor added a comment - only allow delegated user managers to assign roles and groups in which they already belong exception is administrator, who can assign all regardless
          Hide
          Paul Anderson added a comment -

          Limiting the assignable roles to those possessed by the user of the portlet works as an approach, but there is a bug in the implementation.
          When you use the portlet and edit another user's associations, the dropdown list is at first correctly limited to your own roles.
          But if you delete a role, the dropdown then changes to list all the roles on the portal, and stays like that.

          Show
          Paul Anderson added a comment - Limiting the assignable roles to those possessed by the user of the portlet works as an approach, but there is a bug in the implementation. When you use the portlet and edit another user's associations, the dropdown list is at first correctly limited to your own roles. But if you delete a role, the dropdown then changes to list all the roles on the portal, and stays like that.
          Hide
          Ate Douma added a comment -

          I reviewed the current implementation, and while working partly, I found an easier way to implement and complete this one, which happens to also solve JS2-915 at the same time.

          I'm using the current user its fully resolved (hierarchically even) principal list, which is available from the Jetspeed wrapped UserSubjectPrincipal.
          Having those, and when determined the current user does not have 'the' admin role (determined from the PortalConfiguration),
          the current user will only allowed to modify (both add and delete) principal associations for a principal when itself has access (be assigned to) these principals.

          And, going even a bit further: I also disable editing any user principal property/configuration when that user principal happens to be assigned this admin role (except for admin role users itself).
          That is: I only evaluate if the user principal as this admin role directly assigned. So, not checking against possible hierarchical derived admin role because that is very expensive and complex which we currently only do for a logged in user itself.

          Finally, while I was at it anyway, I've also cleaned up the "tabs" a bit by renaming/replacing the "User Profile" tab for Roles and Groups to a new "Status" tab,
          and likewise splitted off the same functionality a new "Status" tab for Users so the Users "User Profile" tab now really only provides "profile" management.

          AFAIK, all works now as can be expected (as described above), and thereby includes the requested functionality from JS2-915 too, automatically

          Show
          Ate Douma added a comment - I reviewed the current implementation, and while working partly, I found an easier way to implement and complete this one, which happens to also solve JS2-915 at the same time. I'm using the current user its fully resolved (hierarchically even) principal list, which is available from the Jetspeed wrapped UserSubjectPrincipal. Having those, and when determined the current user does not have 'the' admin role (determined from the PortalConfiguration), the current user will only allowed to modify (both add and delete) principal associations for a principal when itself has access (be assigned to) these principals. And, going even a bit further: I also disable editing any user principal property/configuration when that user principal happens to be assigned this admin role (except for admin role users itself). That is: I only evaluate if the user principal as this admin role directly assigned. So, not checking against possible hierarchical derived admin role because that is very expensive and complex which we currently only do for a logged in user itself. Finally, while I was at it anyway, I've also cleaned up the "tabs" a bit by renaming/replacing the "User Profile" tab for Roles and Groups to a new "Status" tab, and likewise splitted off the same functionality a new "Status" tab for Users so the Users "User Profile" tab now really only provides "profile" management. AFAIK, all works now as can be expected (as described above), and thereby includes the requested functionality from JS2-915 too, automatically

            People

            • Assignee:
              Ate Douma
              Reporter:
              Paul Anderson
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development