Releases Q&A: 2022-04-16 Permissions Check Permissions when Masquerading as Course Admins

[HeatherAhern]

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

[phanley]

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)

[chriscas]

@phanley, I totally agree with the points you've made here...   Instructure seems to have a very narrow viewpoint on this entire issue.  I am very against this feature being enforced, but if it is going to be enforced against our wishes, we need *MUCH* better documentation about what exact permissions are being checked between admins and course-level roles.  Simply saying "make sure your admin roles have all the abilities as your teacher roles" is not acceptable because account and course roles are not always identical.

As you also pointed out, the "fix" or ensuring permissions can't be escalated when acting as, while well intentioned, is likely going to end up creating even larger holes.  The LTI example is a great example of this...  We may allow Teachers to delete an LTI, but that permission is only tied to course-level LTIs.  If admins have to have the "matching" permission to use "act as", that not only allows them to delete a course level LTI, but also delete our account LTIs.  This is really an unacceptable situation, and maybe something Instructure has not fully thought through.  Basically, we'll have to give almost full root access to any admin we want to be able to act as a teacher...  So now instead of perhaps having the escalated course level permissions of a single user at a time while acting as them, the admin now will have permanent full access to basically every course and account setting.

I am pushing for the feature flag to be permanent, and never enforced, if this change has to be made at all...  I feel like adding a disclaimer about the potential escalation of privileges to the act as permission description would be a better choice than this restriction.  Admins will know the risks and make our own decisions about what to allow.  The only thing I agree with enforcing (which is already in place) is that a person with a limited admin role should not be able to act as someone with a higher admin role.

-Chris

[cw2481]

I believe the same issues come up for Courses - manage/update.  The account level role is needed to for admins to edit the or course navigation of the course but also gives them access to edit the term.  Because of this we don't grant sub-account admins this access and they need to Act As the teacher to edit the course settings or course navigation.

[cdoherty]

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.

[cw2481]

Columbia University has an almost exactly identical setup and this change completely breaks our distributed support model.  Please implement the changes to allow sub-account admins to have permission to act as users that Christine has outlined

[chriscas]

Totally agree with this too!  Instructure doesn't seem to be considering distributed support models at all with this change.  Subaccounts are great in general, but have always been somewhat problematic with the "act as" permission, because user accounts all really live in the root account.  If I'm ad admin for an engineering subaccount and I then act as a student who has engineering courses along with science courses, should I be able to see the science courses?  If act as is truly acting as the student, the answer would seem to be yes, but that also gives me access to courses outside my normal subaccount.   If I get access denied errors or don't see the courses outside of my subaccount when i'm acting as a user, that's also very problematic for troubleshooting issues they might have.  For institutions with distributed support models (including us), we need a way to make act as work without basically giving full root admin access to every support person.  Making a limited role at the root level, while somewhat of a "hack," has worked for us since day one of our Canvas implementation in 2013.  All of a sudden, this is no longer acceptable to Instructure and is either going to force us to give way more permission than acceptable to our support staff, or may force us to reconsider our entire support model (which is not something an LMS vendor should be able to dictate to it's customers on a whim).

Instructure, the issues with this change were not just timing, but the entire idea and implementation of it.  Giving us a couple months before you roll out the same change is not acceptable.  We need this change to be entirely rethought, specifically thinking about how subaccount admins should be able to operate to match their real-world job duties at institutions.

-Chris

[JasonQuist]

This also broke the distributed support model at UChicago, and we had to roll back when it was discovered. Honestly, it's baffling to me that this is being reimplemented as it was introduced.

[terri_milroy]

This issue of distributive support is KEY to many colleges and universities. Our system has only a single root admin that would retain Act As functionality under the proposed change, whereas every college and many campuses/departments have sub account admins that currently use Act As functions to support faculty and to troubleshoot student issues when faculty cannot. The fact that Instructure is not looking at all user permissions for these sub account admins needs to be remedied; either the Act As feature needs to be left as is, or the system needs to be restructured to evaluate all user permissions before removing Act As from that admin.

I had an emergency issue over the weekend where I had to access an instructor's inbox, and could not have done so without the Act As permission. No one else at my institution would have had the function under the new parameters, and it is highly unlikely that we can require a single person to be on call every weekend and holiday to Act As in such emergency situations.

[tlc_OU]

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.

[chriscas]

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...

• I knowingly install a peephole in my front door so I can see if someone is standing outside.  I know in a very limited way, they might be able to look in and get a tiny tiny view of the inside of my house, but i'm okay with that. 
• Someone from the HOA (instructure) comes along and says, "hey we found a major security issue, someone may be able to look into your house!  We're banning peepholes from all doors in 2 months."
• I say, "But I want to be able to see who might be outside, I want my peephole and understand the risks.  What am I supposed to do?"
• The HOA responds, "That's simple, you just remove the door completely, then you will be able to see outside"
• I say, "But then anyone can just walk in the door, that's worse than the peephole issue"
• The HOA says, "at least you know that's what is happening now"

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

[cdoherty]

What a fabulous example.

[vancej]

I am still trying to understand what is the real problem that Instructure is attempting to fix.

[lgekeler]

Same here at the University of Notre Dame.

[Charles_Barbour]

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.

[milesl]

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).

[kroberts]

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.

[Ganelon]

 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. 

[jenn_stevens]

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!

[dtod]

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.

[lgekeler]

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

[akinsey]

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.

[pdurham1]

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.  

[thoffman]

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.

[basingerm]

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. 

[cgl233]

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.  

[rpeloquin]

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!!!!!!!!!!!!!!!!

[vancej]

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? 

[phanks0002]

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.” 

[garrett_wright]

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!

[dbrace]

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... and clarification at https://community.canvaslms.com/t5/Canvas-Releases-Q-A/Releases-Q-amp-A-2022-04-16-Permissions-Check....

++++++++++++++++++++++++++++++++++++++++

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:

• Admins who are given student roles in a course may still be able to view admin features. To avoid permission conflicts, admins should create a separate account.
• When a user needs to act as another admin or a course role(Teacher, TA and Designer enrollment), you want to have all the permissions enabled in your account that have been enabled for that user.
• Audit your role permissions as Canvas releases updates to the permissions. Try to make the role’s permissions as granular as possible.
• When creating a new role, please read the “Additional Considerations” when clicking on the permission. This will give you more insight into what will be affected if the permission is enabled.
• Don’t use a one size fits all role. If a user needs to only do a specific task, create a role that is limited to the permissions needed.

[fsmith4]

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.

[alanm1]

It seems pretty clear that everyone here has the correct solution and it's just a question of Instructure implementing it the way it's being described. Anyone who works with an OPM, has college or department level management of courses or support, multiple-campuses, etc, needs an implementation at the sub-account level. Also, you can't/shouldn't need to match user and admin permissions because they are not identical in scale or scope.

Regarding someone in a student role in a course using distributed admin features to elevate permission inside that course, that's not an Instructure problem, that's an Institution problem. LMS admins that need the student role in a course should be enrolled in that course with a student account that has no elevated privileges, and policy should be in place that prohibits admins with a student role from accessing a course where they are enrolled as a student with the admin account, as that's auditable behaviour. Janking admin privileges to fix that doesn't make sense.

[reynlds]

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!

[Glennnnn]

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?

[jpoulos]

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.

[chriscas]

Hi @jpoulos,

I just wanted to give a sincere "thank you" for listening to the community comments made here by myself and others.  I really appreciate the decision t make the feature option available for the long-term.

I also wanted to say that I would love to volunteer to give feedback in advance of any future changes to this or other things around permissions.  I have long been an advocate for more granular permissions, and Instructure has been doing a decent job at adding granularity over the last couple years.  I know the act-as functionality is very tricky to get right for everyone, but maybe with enough community input we could help Instructure to find a solution that would work for everyone.

-Chris

[Charles_Barbour]

@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?

[jpoulos]

@Charles_Barbour That's correct. There are no current plans to change the default from OFF.