Main Nav



We have a request from some staff to create an impersonation/shadowing function in our portal, so that when students have issues with the portal, it is possible for staff to log in as them and see what they see.  Has anyone implemented something along these lines?  If not, are they are other remote troubleshooting solutions you have used or would recommend?






David Norman Director of Administrative Computing, Bentley University

175 Forest Street, Waltham, MA 02452, W: 781.891.3498  M:  781-697-6239



********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at


Hi David,


This is typically an “authentication provider” issue and not a “portal” issue per se (assuming they are separate) and asking your authentication provider to allow you to impersonate another user breaks some pretty fundamental authentication rules.  We use two methods to address this challenge.  We create “constituency accounts”, so there’s a “typical student” account for example, that can be used for testing and troubleshooting.  For more individual user issues, we fall back on the “show me” strategy that requires them to login.  And for those situations where someone is most effectively supported from afar, a remote support tool like a Bomgar (the one we use and would recommend) works extremely well.





Armand Doucette

Executive Director, IT

MIT Sloan School of Management

50 Memorial Drive

Cambridge, MA 02142


Office: (617) 253-0827





This is a growing issue on our campus with the increase in use of 3rd part systems and Portal integration.   Front line support people at the Help Desk, Student Services and Admissions are demanding to see EXACTLY what a student sees.  Add the fact that the legacy Unix system used to provide the ability to login as someone else and this makes for a very vocal and passionate group on campus.  Of course on the other side of the equation you have security and privacy issues.  Having any kind of cloning or emulating users would have dire audit consequences. 


I feel that even if you find or write a process to do this, the maintenance of it as you add knew systems and authentications could be extreme, and the scrutiny from the auditors would probably not be worthwhile.    


I have taken the high ground saying we cannot exactly emulate any one user.  But we have set up some “generic test” users that represent the various major student populations.  Traditional UG, Transfer, Weekend and Evening Students, Graduate students, New applicants. Etc.  They are well documented and know to the financial group and the auditors. 


It’s not perfect, but it is full disclosure and most students seem to understand that their personalized systems don’t exactly match documentation or support instruction and adjust accordingly.  Our non-traditional age and graduate students have more issues with it.  It could be a generational thing with the texting/facebook generation accepting it quicker than others including staff.  YMMV  (your mileage may vary) 




David Schulte

Director - Enterprise Information Systems

Maryville University

650 Maryville Dr.

St. Louis, MO 63141

(314) 529-9329






Wouldn’t a web conferencing tool with desktop application share allow you to see exactly what the student sees?



(281) 283-2983



I think I would lean toward using a product like the one below where it will capture what the user saw. This way you can see what the user ran into for problems and how they go into this problem. I have seen cases where it was hard to reproduce the problem even if I could assume the identity of that person b/c I didn’t know for sure what they clicked on first, second and so on to get the error. Once you can follow their clicks then you can try recreating the same scenario in the generic test accounts as you outlined below.


I hope this helps.



Certain products (Liferay, for example) have an "impersonate user" functionality that lets you view any page in the portal as another user would see it. It's not their live session, but more a way to validate access control or error messages resulting from what their account is allowed to do.

Daniel Spillers
University of Arkansas at Little Rock | Information Technology Services

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at

Thanks Rich


Norman –


We built something like this, but ultimately we didn’t use it.  It allowed a student to give permission to a set of back office users and then they could login as that person for 15 minutes to see what the student was seeing.  It wasn’t very difficult to build (required customization of the sign-on peopelcode) and was implemented as a part of our read only access for student parents and proxies.


I think it made us all (functional, security, and development)  too nervous from a controls/security perspective and we didn’t release it to the public.  We currently use Bomgar which is a helpdesk remote viewing/control tool.  It’s similar to the affect you get with Webex/GotoMeeting, etc and works on macs and PCs.  Next we’ll have to figure out how to do this on mobile devices I suppose!


Josh Harmon



Message from

For our MyUB portal, which we built in-house, we have a back door facility that allows select personnel to view a user's current view. That includes public data (such as classes taken), but you don't take on their identity so no private data is revealed and if you attempt to click through into any reports or tools, you are thrown back into your own view. This is a wonderful tool. We also provide restricted access to what we called our "transmogrifier", which allows you to temporarily transform your own view to mimic the roles of a very specific user type, drawing on all the available roles in the portal. This is very handy for development and training, but since it doesn't provide details for a specific individual, there are important limitations. We also provide public access to a set of demo views for a generic student, staff member, and faculty, which are handy for orientations and demos. Lately all three have become less significant, since all our transactions and reports are now occurring within a deeper level, in an PeopleSoft system. But the more basic ability to view a specific user's view is still very handy for support and development. With apologies for its antiquity, here is our now very dusty project site: Cheers, Hugh Hugh Jarvis (PhD, MLS) Cybrarian, University Communications 330 Crofts Hall -- University at Buffalo Buffalo, NY USA 14260-7015 Ph: 716- 645-4604 Fax: 716-645-6969 Email: (preferred) Visit our Facebook site: and new Google+ page: Please consider the impact to the environment before printing this e-mail. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at
Here at the U of M we're using a portal built on the Metadot platform and heavily modified. We have three levels of impersonation/shadowing.

--A handful of staff on campus have the capability to log in and see exactly what a specific user sees. This is used only for support purposes when all else fails.

--A slightly larger group has the ability to see only targeted areas of the portal for a specific user (for example, the page that displays a user's classes and links to their course web sites). Again, this is used for support purposes as well as for testing to make sure things are displaying properly.

--We also have a function called "content provider preview" which allows someone to log on and see what a specific audience sees (for example, students in the Class of 2013 or faculty in the School of Nursing). We have a very modular portal with content cells that are filled by units across the system. The preview function allows a content provider to see how his/her own content appears in relation to the rest of the content a specific audience is seeing. No personal information for another user is displayed. This functionality is provided to about 250 individuals across the entire U of M system - content providers and other interested parties.

I'm not a technical person so I can't tell you how any of the above was engineered, only that we have it.
Sandra Ecklein