Hi Steve, You may already be able to identify a swapped session by looking for the LoginController.SWAP_TARGET_UID attribute in the session. Assuming you find that that's successfully populated for swapped identities, you could create a new UserInfoService to expose a flag to interested portlets. If it's not available, you could take a look at the FragmentAdministrationHelpers, since swapping specifically to fragment owners is definitely tracked in the session.
It's worth noting that delegated authentication often helps mitigate the information visibility issues described here. For a school that's using proxyCAS, delegated Shib, or credential replay, the user's layout will render, but credentials won't be available for replaying information from external systems such as enrollment, email, etc. In general I'd recommend thinking hard about the administrative privileges in the portal and who should have access to them. It's also worth considering what other access administrators typically have. If the group granted impersonation rights has access to the portal database and administrative access to enrollment and email systems, it may be less important to create additional privacy controls than if the permission is being granted to a more limited admin working at a helpdesk. Locking down portlets will also prevent an administrator from being able to walk through a problematic workflow on a users behalf or use UI controls to assist a user with configuring a portlet. If this feature is implemented, I'd recommend that its use be configurable, since different institutions will have different opinions about whether portlets need to be suppressed. - Jen On Jul 11, 2012, at 10:30 PM, Steve Swinsburg wrote: > Hi all, > > We have been conducting a security audit of our portal and have discovered a > situation where data of another user can be exposed via the Switch Identity > portlet. > > For example, an admin user uses the Switch Identity portlet to switch to a > student, then can view that user's timetable and enrolment information, which > is meant to be private. A similar case applies to the email portlet. There > are other scenarios as well, as you could imagine, since you are effectively > being logged in as that user and can see and edit everything they can. > > Aside from further locking down of the list of users that can access the > Switch Identity portlet, we are proposing a minor enhancement to the portlet > itself which is to set a session attribute that signals that the user is > impersonating the other user. Portlets could then read that session attribute > and if they display private information, decide not to render themselves. The > attribute would then be cleared at logout time. > > This should be a non obtrusive modification and the changes to portlets only > need to be made as required. For example we would change our own local > timetable portlet, but not worry about the weather portlet. > > We are interested to hear peoples thoughts on this and comments on the > proposed solution. If all is ok, I'll write it up in Jira and get it done. > > cheers, > Steve > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
