Hi Jen, Yes, I was thinking that the fragment admin must do something similar since it knows you are swapped.
Kevin wrote earlier about the "Hide portlet during impersonation", does that feature of uP4 do what we need already? The restriction of access to these functions is certainly something we are doing in the interim, we just want a longer term solution since we don't have (or any easy way to auto populate) defined groups for certain admin functions. And the implementation would be purely up to the portlet itself. Right now we are only looking at our own portlets which expose private info, timetable, some basic LTI connections, etc. Though if the feature that Kevin describes does what we need then we might look towards that one instead. cheers, Steve On 13/07/2012, at 2:07 AM, Jen Bourey wrote: > 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 uportal-dev@lists.ja-sig.org as: >> jennifer.bou...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > > > -- > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > steve.swinsb...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
