Looking to discuss this feature from the 2022-04-16 Release Notes? Post a reply and start a conversation!
POSTING GUIDELINES This topic is for feature discussion only—please share use cases, best practices, etc. regarding this feature Please thread replies as much as possible to keep posts organized WHERE SHOULD I POST...? Idea enhancement feedback to product managers should be submitted in ideas.canvaslms.com (though linking to the idea here so others can find it is welcome) Bug reports should be submitted to Canvas Support—bugs will not be triaged in this thread
WHERE SHOULD I POST...?
This feature causes a bit of of a headache for us at the intersection of Course and Account roles and permissions -- we have support people who do faculty support for the university (across colleges and units) and others who are limited to a specific college of unit, and all of them use the Act As... feature for both issue support as well as supporting course configuration and design.
Due to governance policies around LTIs, no support roles should have the Manage LTI permission to install LTIs on the account level, which is where we are running into trouble (we currently have that permission added to the affected roles, but this is sub-optimal from a governance standpoint)
In order to Act As... an instructor, the support user needs to have Manage LTI (but technically only at Course level) as we allow instructors to install LTIs in individual courses to allow for publisher tools, etc.
Is it possible for an additional Account Role permission could be added -- Manage Course LTI, and perhaps rename Account > Manage LTI to Manage Account LTI? It could alternatively be formatted like other Course-related account-level permissions , e.g. Course LTI - add /edit / delete (of course granularity is always preferred)
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.
I ditto what Christine has posted; at the University of Oklahoma, we leverage sub-account admins to help manage department- and college-level Canvas support needs, and the ability to masquerade as a user is something that needs to be restricted to their particular sub-account. Enforcing this "feature" without taking into account how many institutions manage Canvas on a day-to-day basis is befuddling at best.
I know I made a couple posts above, but I want to make one more post with a little make-believe scenario here which might help Instructure see this in a similar way to me...
Is there a potential issue with "act as" as it stands today? Yes. While the "fix" does close the escalation of privilege issue, for those of us who need to give the act as functionality to some users, we now are being forced to give almost full root admin access which opens up a much larger issue than the original one.
-Chris
Same here at the University of Notre Dame.
Does Instructure not understand the distributed support use case, or do they not care about breaking it?Those are the only two possibilities I see.
We at Berkeley would also be negatively impacted by this change, as we have sub-account level admins who currently have been granted a limited permission root-level admin role (solely to get masquerade permissions).
They would no longer be able to perform their job duties if this change is implemented.
An ideal outcome would be to:
1. Keep this change as a feature flag until
2. The masquerade permission can be granted at the sub-account level (Act as User (Masquerade) for Sub-Account Admins - Instructure Community (canvaslms.com))
This would allow schools to perform our own risk assessment, and eventually simplify our complicated permission structure (which would lead to fewer errors/increased security).
The University of Washington has account-level roles set up just like Berkeley, in order to provide distributed admins in colleges, schools, and departments robust control over their subaccount. We have a root-level role that only grants the "act as" permissions and it accompanies a fairly privileged subaccount admin role. I endorse the suggestion to keep this change a feature option until the act as permission can be granted at the subaccount level. If the change is enforced in June, UW will either be forced to provide robust permissions at the root account level to more admins, or entirely change how the distributed support for Canvas with subaccount admins works at UW with a very short window to do so.
Deer Valley Unified School District is in this same boat too. This needs to be an option to turn on. This should be choice. Give people some time adjust workflows and figure out how this can be used, if they choose to use it.
We too are planning to leave this off, and would not want it enforced.
One use case I haven't seen mentioned so far is this one: An OPM designs and provides student support for one of our online degree programs, and we have given them admin access to manage their sub-account. We created a special role at the account level that only has "Users-act as" and "Users-manage observer", to allow them to masquerade as students in the subaccount where they can view classes. We do NOT want to create more permissions for them at the account level (ie, there is no need for them to have permission to create discussions at the account level), but need them to have full admin abilities in the sub-account.
When testing, we found this feature does not allow the subaccount admins to masquerade as "course admins" aka teachers. It defeats the point of outsourcing support to not let the support people... provide support!
Ditto Virginia Community College System. Very specifically, this key issue:
"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. "
We have a root account role with a very limited set of permissions including Act As..., but the holders of the role have more comprehensive permissions on their college-specific sub-accounts, so that they work together, but this feature breaks that entirely.
Is the point to require the subaccount admin to add themselves to the course as "Designer" and then do whatever they need to do rather than masquerade? That would make a subaccount admin members of who knows how many course sites! ~LauraG
This is extremely problematic for our community college system with our distributed access. This is true for multiple institutions that I am connected with as well. This should not be enforced across institutions and instances of Canvas--if it needs to remain, keep it as a feature flag.
If security is the issue, this is not the solution. The ability to act as an instructor allows me to troubleshoot and fix problems that come from Deans, VPs, and students. If this feature is introduced and enforced, I hope that Instructure plans on hiring a large number of people to field the calls that will now come from both instructors and admins. This was not thought out before it was planned. This feature allows for onsite support for teachers. In my department, we do not work with students, ONLY with faculty. So that would remove us as support for faculty to troubleshoot and fix things remotely. There are great comments here, and not a single one supports the continuation of this feature. It will be interesting to see if the "community" actually has a voice and if Instructure listens and removes this after all.
Unfortunately the last time this "feature" was attempted, it caused major issues for our Community College System. Our Administrators are SUB-ACCOUNT admins because we have 23 schools making up the system. This tool only looks at the root level for accesses. We lost the ability to Act-As teachers. This sounds small but it is a critical part of troubleshooting and verifying instructor issue reports. It would be more helpful for the process to look at sub account accesses as well as root accesses for a full composite of what the administrator can actually do. The way this is working so far, the two choices are 1) Don't troubleshoot to see what the actual user is experiencing, or 2) grant every college administrator full administrative access at the root level. That last choice will actually weaken security, not augment it.
Acting as the instructor allows me to effectively troubleshoot issues instructors have not only with Canvas but LTI's as well because I can see in their course through their perspective. It is also unacceptable that a decision that limits our support effectiveness can be made by Canvas without asking their stakeholders if they want this feature disabled.
Canvas: What are you thinking??!
As others have posted, this is a huge problem for support. In today's environment of online learning, teleworking, etc., it is baffling to me that a Learning Management System company would make changes which would hinder support/troubleshooting/assistance/etc. As an LMS Admin, I frequently get support requests from faculty which require me to see what they see. With this feature change, I will either have to be face to face with faculty (many faculty are not on campus), do a Zoom meeting (this is problematic with adjuncts and dual enrollment faculty), or have them send me lots of screen shots and try to fill in the blanks. This extremely decreases productivity and workflow.
If the issue is security, and teachers questioning whether LMS Admins/support can "change" their course, that's concerning to me. As support personnel, we are here to help, not to hinder. We also have understanding about privacy and security, as well as intellectual property. The settings cannot be such that opposite ends of the spectrum are both satisfied. We cannot provide adequate online, remote, support for teacher/Canvas issues if we are not trusted enough to have access to what we need to see in order to provide that support. The whole idea seems asinine to me.
The 'act as' is extremely helpful when troubleshooting Canvas issues for instructors. It is the only way that I can see what the instructor is seeing and experiencing, to help to resolve issues. Not having this functionality would be a major issue when working with instructors. I will now have to contact a Canvas L1 representative to assist me with issues, when before I could many times resolve them on my own, by acting as users. PLEASE DO NOT REMOVE THIS FUNCTIONALITY!!!!!!!!!!!!!!!!
I do not understand the problem that this feature is attempting to address. Enabling this feature defeats the purpose of sub-admins, unless institutions will have a buffet of primary admin which seems just as illogical. Or each sub-account become their own separate instance of Canvas. Meaning, an university that has several schools/divisions would have a separate instance of Canvas for each school/division instead of one instance with several sub-accounts.
Again, why adjust the primary sub-account admin support abilities to solve what problem?
As a college Canvas administrator, I along with others in our Community College System respect the role and recognize that security is paramount. The “masquerade”/ “act as” feature has been very helpful in problem solving issues instructors, staff and students face immediately. Most especially being able to remotely help others has been a life saver as sitting side by side with folks is no longer an option. One can only assume the Canvas Cooperation must have hired many new support folks who will provide IMMEDIATE faculty support when this feature is discontinued. I am disappointed that as a Company, Canvas is not listening to the Power Users who serve as “boots on the ground.”
This is a major problem for sub account admins. Acting as the instructor allows me to troubleshoot any issues instructors have in Canvas and especially studio. Please do not remove this option!
UPDATE -- Make sure that you read @jpoulos' comment at https://community.canvaslms.com/t5/Canvas-Releases-Q-A/Releases-Q-amp-A-2022-04-16-Permissions-Check-Permissions-when/m-p/520013/highlight/true#M854 and clarification at https://community.canvaslms.com/t5/Canvas-Releases-Q-A/Releases-Q-amp-A-2022-04-16-Permissions-Check-Permissions-when/m-p/520122/highlight/true#M856.
++++++++++++++++++++++++++++++++++++++++
Due to the size of my institution and our technology and Canvas support structures, this change will not (at least currently) impact us. Regardless of that, I reached out to my CSM and requested additional information. The reply that I received from them is provided below.
++++++++++
On March 16th, we deployed code to resolve a security gap for users with admin permissions that allowed them to increase their course level permissions through masquerading. Admins with the “Users - act” permission were able to act as course level users with more permissions than they have. This allowed admins to escalate their course level permissions beyond what they have been allowed. When we deployed this code, several institutions experienced issues due to how their various admin roles were established. As such, on March 18th, our engineering team reverted the deployed code to give our customers the time to make the necessary adjustments with their user permissions to align with this change.
Our CX team partnered with our Product and Engineering team to identify the best path forward for deploying code to resolve the security gap identified with admin permissions. In the April release (16th), we will deploy this code with an associated feature flag set to the “Off” position. In the June release (18th) we will turn on and lock this feature flag to the “On” position and remove the flag in July (16th) release. For institution’s unaffected by this change, they will be able to enable this feature in April and close the security gap with their admin permissions. For those institutions that were affected by this change, they will be able to turn on/off the feature flag and test their permission updates between the April and June release. This feature will also be available in institutions Test instances if institutions wish to test their adjustments in that environment. This information has been added to the April Release Notes, and there is a Feature Option Overview as well.
Our team has partnered with our engineering and product teams to help put together best practices for institutions to follow as they make adjustments to their admin permissions. Please see the following set of guidelines below:
It's clear that Instructure believes making this change will increase security, but, based on how schools with distributed support will have to redesign their system roles, the opposite is going to happen. Institutions are now going to have to provide more people with more permissions than they have previously had or probably would want them to have.
Besides the distributed support model that many before me have pointed out, we have active development that requires the masquerade function in order to populate an external mobile app with course items (such as individual due dates) for students from the Canvas REST API. Basically the service proxies students to be able to act as themselves. Beyond this we'll have to re-develop the entire process and implement an OAuth2 workflow, which is counter to our original directions that students should NOT be prompted to log in to an app in which they are already authenticated. I could go on, but this is now going to cost us money and time and it's an undesired result of something that (until now) was certainly not broken!
Enforcement of this feature will wreck the support model used by the 23 colleges in our system. Judging by the comments here, many other institutions will experience similar consequences. We know you already know this, so it seems that you don’t care enough to find an alternative solution. Does this seem like a wise business decision to you?
In response to the valuable feedback provided here, we've decided to keep this feature option in a default OFF state for the foreseeable future. Institutions that would choose to adopt or abstain from this feature will not be prevented from doing so. I will be working with our releases and documentation teams to ensure this is clearly stated through our community notes.Thanks to all who have expressed their frustrations and concerns, and those who supported them. The use cases and insight provided here have been invaluable and provide us with a lot to consider as we improve our permissions system.
@jpoulos , that sounds like good news.
I do want to make sure I understand this correctly though because @dbrace shared a response from their CSM which stated:
"In the April release (16th), we will deploy this code with an associated feature flag set to the “Off” position. In the June release (18th) we will turn on and lock this feature flag to the “On” position and remove the flag in July (16th) release."
Are you saying that's no longer the case? There are no longer any plans to turn the feature flag on on June 18th and eventually remove the flag entirely?
