Support #3571

Question regarding WEB service authentication tokens

Added by Vadim 3 months ago. Updated 3 months ago.

Status:ClosedStart date:06/15/2020
Priority:NormalDue date:
Assignee:Vadim% Done:


Target version:RapidDeploy - 5.0-FIX
Affects Version:5.0-FIX Additional version details:
Timesheet Code:



RD do have special encrypter for token generation. That token can be further used for user authentication when triggering plan jobs from Jenkins. Everything works fine. Just one question to make it clear if I understand everything right:
As soon as RD uses AD for user authentication it uses this authentication mechanism all over the system, so WEB call with token will also be decrypted and used to authenticate user using its user name and password in AD. Is that right? If so then each time user changes password it is necessary to regenerate token as well. I'd say that such system is not so great. :) Maybe from security side that looks Ok. But from user side... Don't think so. In our case each user that works with code should connect to Docker container and do some manipulations there to achieve new token. Then he has to update token in Jenkins. Too much movements... Don't You plan to change this system? :) To allow users to have tokens that are not directly connected to their AD credentials?

Why am I asking about this: At this time system is configured so that Jenkins triggers deployment in RD with one fixed user. And all deployments are executed with that user. But I would like to see the real information about who made deployment, who initialized it. Jenkins does have user e-mail from GitLab and passes it to RD as a project parameter (it is used to inform user in case of deployment fails). Jenkins could have list of all users tokens and use those to trigger RD works. But I don't like that users have to setup tokens each time user's password changes. That's a place to make mistake.

Maybe You can offer any other possibility to implement the system I described?

Best regards,


#1 Updated by Rafael 3 months ago

  • Status changed from New to Feedback
  • Assignee set to Vadim
  • Target version set to 5.0-FIX

Hi Vadim,

Let me try to help you, although I don't quite get your concern.

You have to understand the authentication token as an encryption of a certain user credentials, it's not a different way of authentication, it's the same authentication you would use from the graphical web console but encrypted as an extra security feature, because it's usually travelling through the web as a web service request.

We obviously do not force any particular security policy from the RapidDeploy framework, but if your company security policy forces a user password reset every certain time, it wouldn't make sense we don't respect it and break the policy! :-)

I can understand the password reset in the AD server would mean the need of changing the authentication token in the Jenkins server and is quite error prone, but I can't really think of an alternative. Also, I guess this is not a very frequent thing, so I suppose a user can waste a couple of minutes updating his authentication token whenever his password is reset in the Active Directory server. :-)

Although is not the best solution to keep track of the users triggering the deployment, I guess you could just use a generic "jenkins" user as you're doing now, and just pass the particular user who's deploying as an extra parameter the same way you're doing with the email.

I'm sorry I can't be of much help, but it's a very trick question! :-)



#2 Updated by Vadim 3 months ago

Hello, Rafael.

I didn't say that You should change this system. It's nice and it works. Just thought that maybe You have any alternative that could eliminate token change or make it easier. As I understand there is command line tool only, yes? No any WEB API? Maybe it's possible to get that encryptor out from the server to make it easily accessible?

Regarding the generic user as I did it now - that's not so clear who initialized deployment when looking at the list. It's much more useful to see user just from the list than trying to get it out from deployment packages.

Ok. That was just a question about how to make it in a most easiest way. :) So if You can suggest anything - I will be thankful.

Best regards,

#3 Updated by Rafael 3 months ago

  • Status changed from Feedback to In Progress
  • Assignee changed from Vadim to Rafael

Hi Vadim,

All questions and suggestions are always welcome! :-)

I can try to provide an easier to use and self contained "encryptor" to generate the authentication token, so you don't have to log in to the container every time you need to generate a new token, but even though, you will still have to update the token in Jenkins.

That's the bets solution I can think of, because if your company requires you to change your password every certain time, there's not much we can do but update indeed this password in Jenkins... :-)

Let me think of a good solution and try to provide you with the easiest way to generate the authentication token!



#4 Updated by Vadim 3 months ago

Hi, Rafael.

Oh, that's great! There is no great problem with Jenkins as I can do that when I have user's token - it is saved in Jenkins' credentials store with admin user. The main problem now I see is as You say - login in to the RapidDeploy container to get token. If there is real possibility to have it as a separate service or event just file - that would make the process simpler.

Will be waiting for a good news! ;)

Have a nice day!
Best regards,

#5 Updated by Rafael 3 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from Rafael to Vadim

Hi Vadim,

I have just realised we actually provide a web service to generate the token! :-)

It is not published in our documentation and if you want to use it, it will be at your own risk, as the actual credentials will be travelling through the net.

You can just perform a POST request to the following URL:


With the following JSON body:

{ 'param1': 'mvadmin', 'param2': 'mvadmin'}

Where "param1" is the username and "param2" is the password, and the output will be the text with the authentication token:


Although it's been there for a while, I wasn't even aware of this web service, that's why I didn't tell you at first, but a colleague of mine reminded me about it! :-)

The second option is to use the current encrypter script. You can find it in the following link:

It's just a very simple version of an authentication token encrypter. It is in fact just a reduced version of the actual RapidDeploy package, you can easily realise this.

You can just normally call the "" script inside the "tools" folder and input the credentials required from the command line interface, or you can call it with the parameters already set for which you're not required any input:

./ username=mvadmin password=mvadmin

One very important thing if you want to use this method

You need to have the same value for the "rapiddeploy.key" property in the "" file inside the "bin" folder of both the RapidDeploy server and the encrypter folder.

If you don't do anything, we provide a default value that's transparent to the user inside the framework, that's why you don't see any value by default in the "" file, but if you want to provide an extra layer of security with your own key, you need to have the same value in the RapidDeploy framework and in the "" file that's in this little encrypter tool.

I hope it's all clear enough, let me know otherwise and I'll try to explain better myself! :-)



#6 Updated by Vadim 3 months ago

Hi, Rafael.

Thank You very much for the information!
Today tried WS API. It works! :) I just noticed that when requesting with "content-type: application/json" service does not return token. Only with "content-type: text/plain". But the main thing is that it works! That allows us to make token update almost automated as Jenkins also has possibilities to update credentials through WEB API.

So thank You one more time! :) Ticket can be resolved.

Best regards,

#7 Updated by Rafael 3 months ago

  • Status changed from Feedback to Closed

Thanks Vadim!

Good news are always welcome! :-)

Also available in: Atom PDF