User Impersonation

Here is a common problem.  You have a custom command that you want people to use, but it does something that requires admin privileges.  Making everyone an administrator is a bad idea.  A better solution is for your command to perform an action as another user.

Vault doesn't support a true impersonation model, but there is a workaround that works pretty well.  Just have your program log in as another user to perform the special task.  Log out as soon as the task is done and let the rest of the operations be performed by the logged-in user.

Recycle Bin 2.0 makes liberal use of this technique.  The whole program rests on a special "Recycle Bin" folder where files go before they are deleted.  Obviously this folder needs to be locked down from normal use.  All interaction with the Recycle Bin folder needs to be through one of the custom commands.  To enforce this, the administrator needs to designate a special Recycle Bin User, which is the only one allowed to interact with the Recycle Bin folder.  Any time a Recycle Bin command is executed, the code logs in as the Recycle Bin user in order to interact with the folder.

Considerations:

First, your code needs a way to know how to log in as the impersonated user.  In practice the impersonated user is usually an administrator, so you have to keep the password hidden from the end user.  There are various ways to fix this.  You can hard-code the password, or you can encrypt the password and put it in a common location. 

Next, there is the issue of licensing.  If you log in as two different users, you will consume 2 licenses.  If licenses are tight, then impersonation might not be an option.  Logging out the original user is not a good idea because what if all the licenses are used up when the operation is over an they try to log back in? 
The best approach is to use the impersonated user only as long as needed.  When the operation is over, log out immediately to free up the license.  If all goes well, it shouldn't have a noticeable impact on the licenses being consumed.
Also, make sure to handle errors properly.  If errors come up during the operation, you still want to make sure the impersonated user get logged out at the end.

Lastly, impersonation has an impact on data history.  Let's say you have an operation that uses impersonation to move a file to the Released state.  Later in time you want to see who released a certain file.  That becomes hard to do since the history of the item will show the impersonated user as the one who made the change.  What you want to see is the actual user. 
This can be solved by storing the actual user as a piece of meta-data, such as a UDP value.  It's not a perfect workaround because the data you want is not in the place where you expect it to be.