Start a new topic

Impersonating a Specific User in powerJobs

Can someone make me an example of how I would have the job processor perform a Vault operation "as a specific Vault user".  That is, I want to have an operation done while impersonating a known user so that the Vault records them as the person of record for the action.  I would like to be able to determine this user from context information in the Vault - most likely by looking at the user who performed the release but possibly by looking at another property that actually explicitly stores a user that I want the job processor to work for.

For example - if on release we create a powerJobs job that publishes several artifacts for every design:

  1. PDF of primary drawing
  2. PDF of drawing of purchased parts
  3. DXF Flat Pattern for any sheet metal

In all three cases I want to copy those files to somewhere on various shared drives and/or email someone about them.  However, it is very possible that i also want to check them back into the Vault - either next to their source files or somewhere else that is appropriate to the functional group that needs to take over next (procurement, sheet metal fabrication).

However, I don't want the files owned by Administrator or some other fictitious user that runs the job processor.  I would like the PDF to be checked back in by MaryD who was the manager who released the final design and the DXF Flat Pattern to be owned by KevinR who is the person who approved the sheet metal a couple of lifecycle steps back.

I know we have done this for customers in the past but I don't remember if we had to write a little bit of Vault API code to do it or if it is all possible in powerShell.



1 Comment

Hallo Milt,

I have to major concerns about that approach.

  • If you impersonate a user you still need a way to identify the versions modified by powerJobs. Otherwise that user would be responsible for potential issues as everything looks like the user did the changes. 
  • In order to impersonate multiple different Vault users you'd need all their passwords. This means you need to store user passwords somewhere, which is a huge security risk. Also it would be quite difficult to keep track of password changes. This could be differently for AD users, but I don't really know about that.

For the actual impersonation you need to create a new Vault session to login with another users credentials. This probably needs to be done in a separate runspace to avoid conflicts.
I know we did this in the past with one specific user that had elevated permissions. We used that in client code for certain actions that a user would normally not be able to do.

Login or Signup to post a comment