We need to adjust our deployment process so that each user triggering a deployment has to pass his/her own oauth token that would be then used to authorize a call to a downstream system. I want my Octopus users to obtain their own token, fill it to some setting/vault in Octopus so that Octopus stores it and they don’t need to fill it during every trigger of deployment. I didn’t find such option, but maybe I don’t know where to look, is it possible?
thanks
Hi @lukasz.podolak,
To make sure I give you the best possible answer I was hoping to get a bit more detail on your use case.
Is each deployment going to different infrastructure / app instances based on the user, or is it all going to the same place but you just want to use deployer specific tokens during the deployment?
Looking forward to hearing back.
Best,
Jeremy
Hi @jeremy.miller - it’s the latter: “use deployer specific tokens during the deployment”.
Appreciate any help 
Thanks for confirmation.
I think the easiest way to do this would be to store them as variables like this:
Variable Name = Token
Variable Value = #{UserToken[#{Octopus.Deployment.CreatedBy.EmailAddress}]}
Variable Name = UserToken[jeremy@gmail.com]
Variable Value = SENSITIVEVALUEHERE
The top variable, Token, when used, will go find the user’s token based on who created the deployment. So for instance, if I created it, it would fill in that nested variable with my email address, then it will go find the variable which lines up with my email address, and it will fill in my Sensitive Value token. You would need a variable for every user’s email address and their associated value.
An alternative approach would be using Tenants, but that’s much more heavy handed and far more setup and also changes how your project works (and won’t work if you’re already using Tenants.)
Just for curiosity sake, can I ask what the use case for this is?
Please let me know if that works for you or if you have any questions.
Best,
Jeremy
Hi Jeremy,
Thanks for feedback
.
I see your point and this probably would work (haven’t tested yet), though all these user variables would be visible to all who have admin access. Ideally, I’d like the values to be controlled by users, just to be kind of personal vaults.
I guess I will base my solution on prompt variable requiring user to enter the token instead.
The use case is that our Octopus instance triggers deployments against another, middle-layer, home-grown CD system which is expected soon to enforce requirement of an oAuth of an individual person triggering deployment. That’s why I need to pass it via Octopus.
Hi,
Prompted variables would definitely work, but that has the downside of manual work and a potential area for human error.
They could be sensitive variables so admins couldn’t see them, but they would be able to edit them. (this would be visible in an audit log, though.)
If it needs to be somewhere no Octopus Admin can access, you could potentially have it as part of a process to go retrieve a value from an outside vault that only that user has access to. Potentially using the same logic as the above, based on the user’s email address, go find the correct vault and value. I believe there are some community step templates that retrieve values from vaults that you may be able to adapt if you want to go down this route.
Do either of those sound like they would work for you?
Best,
Jeremy
I’ll need to evaluate these steps as I was hoping to get something easy to use. Anyway, I appreciate your willingness to help as much as you can, kudos!
1 Like
You’re very welcome! Please let me know how it goes if you get time or if you have any questions along the way.
If I don’t hear from you til then, I hope you have a great rest of your week.
Best,
Jeremy
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.