"su" Equivalent for Auth web application, design question

Question

I develop and maintain a client portal written in Perl / Catalyst. We use Catalyst authentication plugins (with an LDAP storage backend, combined with several deny_unless rules, to ensure that the right people have the correct group membership).

Often when managing client permissions, we need to check user preferences before we move on. Currently, our only resource is to reset the user password and enter the system independently, but this is less than ideal, especially if the user has already set their own passwords, etc.

My question is this: for Catalyst, does anyone come across a method of impersonating a user account in such a way that, given the correct super-administrator privileges, you can temporarily impersonate another account by checking the settings and then backtracking once done?

If not in Catalyst, how did people approach this in a different framework or in their own decisions? Admittedly, this is what introduces a potentially egregious attack vector for a web application, but if enforced, how do people approach the design for this? Maybe some serious cookie-session-fu? Or perhaps the actual system ID / effectiveID?

Answer 1

We use a user authentication controller, a user class (MyApp :: Core :: User), and several areas:

package MyApp::Controller::Auth; ... sub surrogate : Local { my ( $self, $c ) = @_; my $p = $c->req->params; my $actual_user = $c->user; # save it for later try { $c->authenticate({ id=>$p->{surrogate_id} }, 'none'); $c->session->{user} = new MyApp::Core::User( active_user => $actual_user, effective_user => $c->user ); $c->stash->{json} = { success => \1, msg => "Login Ok" }; } catch { $c->stash->{json} = { success => \0, msg => "Invalid User" }; }; $c->forward('View::JSON'); } 

In myapp.conf I use something like this:

 <authentication> default_realm ldap <realms> <ldap> # ldap realm config stuff here </local> <none> <credential> class Password password_field password password_type none </credential> <store> class Null </store> </none> </realms> </authentication> 

This way we create a regular Catalyst custom object, but wrap it around our custom class for more control. Perhaps I could create a specialized area for a surrogate, but instead I chose my own custom class. This was done some time ago, and I can remember why we did it.