Feature Request: Evergreen "su/sudo" functionality

[Chris Sharp]

On the PINES staff we often have the need to see things from the perspective of the logged in user who is experiencing a problem. Currently, the only way to achieve this is to have the user share their login credentials, which is something we generally discourage for obvious security reasons. My idea is to have some sort of authentication mechanism by which a staff member with the proper permission could switch to another user (similar to "su" or "sudo" in the Unix/Linux world) and perform actions effectively *as* that user.

I can already one problem with this idea that would need to be solved before it could happen, including ensuring that auditor functions somehow "know" that the user was "su-ed" to when an action was performed for transparency's sake. There are probably other things I'm not thinking of.

[Dan Wells (dbw2)]

It's been a while, but most of this idea should be pretty simple using the AuthProxy.pm infrastructure. It was written in an attempt to be extensible, and one of the mock extensions we had way back one was called 'MasterKey', which essentially let you have one hard-coded password to authenticate *any* username. I could dig it up again as proof of concept, but there really wasn't a whole lot to it. One could also extend that idea in various ways (e.g. tie it to certain user passwords instead of hard-coding, etc.).

It isn't exactly what you are after, but it might be a place to start, even if just for development.

[Chris Sharp (chrissharp123)]

Dan,

Yes, I would love to see your proof-of-concept branch if you have a moment to share it.

Thanks,

Chris

[Bill Erickson (berick)]

Bug #1468422 includes a new open-ils.auth_internal service that is used for creating users sessions when the password is unknown. Might come in handy.

[Dan Wells (dbw2)]

Okay, proof-of-concept is uploaded here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1528627_masterkey_poc

working/user/dbwells/lp1528627_masterkey_poc

Worked for me in very basic testing, but obviously not something you would want to use lightly. Great for firewalled dev servers :)

[Chris Sharp (chrissharp123)]

Dan,

I finally got around to testing your proof-of-concept. It worked well for me. Do you have a sense of what would be recommended before implementing this in a production instance? We currently don't have open-ils.auth_proxy enabled.

Thanks!

Chris

[Galen Charlton (gmc)]

I personally wouldn't be at all comfortable having that proof of concept be recommended for production use; at the very least, the password should be hashed so that an inadvertent committing of opensrf.xml to the wrong local repository doesn't expose the keys to the kingdom. Of course, we already have all of the code needed to implement bcrypt hashing.

Looking at it more broadly, some desiderata for a sudo mechanism I see include:

* as Chris already mentioned, explicit auditing and logging of when it gets used
* adding a user permission specifying whether a user can sudo; that would allow better control than a global master password would
* some mechanism to control which users a sudoer can "become"; you might want a trusted local admin to be able to act as other users in the same system, but not globally.