When this change to masquerade functionality was first introduced, it prompted outrage from higher ed institutions, since it had ruined important workflows for admins. The solution now is simply to implement the exact same thing, with the same exact problems, only later. The takeaway of this outrage for Instructure Product seems to have been that the only thing wrong with this change was the lack of warning, that customers merely needed time to prepare and adapt to this bad design choice, rather than realizing the design choice was bad and should be fixed.
Therefore, I’d like to explain to Instructure Product why this change to the implementation of masquerade functionality is an abject failure.
The whole purpose of sub-account admins is to distribute user support to department admin teams. In order to make the best use of this configuration, those admins need to be able to masquerade as users in their own account/department. It is also important they do not have access to courses or users outside of their department.
First, Instructure took the Act As permission out of the sub-account level, even though it worked well there and there was no reason to remove it. With this permission only working at the root account level, we had to create special roles at the root account with solely this permission. All other permissions are set at the sub-account level to ensure department admins only have the permissions to view their own department’s courses and users.
Second, Instructure has now implemented a workflow where the admin using masquerade has to match the permissions of the user they are masquerading. This in itself is fine, but the implementation is the problem. Only the role with the Act As permission is checked for this permission match, rather than combining all permissions set for the user in their sub-account role and their root account role. In order for any sub-account admin to actually use masquerade, they would need to have full permissions at the root level, which gives them access to all the courses and users throughout the whole university. This utterly defeats the purpose of a sub-account admin and distributed support.
There are several solutions to implement this security measure without destroying necessary functionality.
1) Reinstitute the Act As permission at the sub-account level. It was there years ago and there’s no reason why it shouldn’t be there again.
2) Implement the permissions check so that it combines all the user’s account roles, both the root level account that has the Act As permission AND any other account role at a sub-account level, where the user to be masqueraded is a member of that sub-account.
Either of these solutions will ensure the security standard is met, while still allowing admins to do their jobs properly. There’s no excuse to do otherwise.