Support for Authentication Tokens

[enaess]

Is your feature request related to a problem? Please describe.

In our deployment we are seeing some network instability in which causes jfrog-cli to fail occasionally. Under the covers, jfrog-cli is calling multiple REST API calls including api/security/encryptPassword, and api/security/token, in addition to a few more calls related to telemetry. While we can disable the telemetry calls by setting the environment variable JFROG_CLI_REPORT_USAGE = "false", there is no way we can configure the jenkins-jfrog-plugin to avoid calling the other security API calls. While ultimately, the unstable network is the root cause; it is good programming practices to retry the operation in which currently the jfrog-cli is not doing and is causing us frequent build failures.

We are running the jfrog-cli in a docker container where the Jenkins tools directory is mapped inside of the container. The configuration should remain in the workspace@tmp directory which dedicated to mapping secrets into the workspace, and is discarded after the build is complete. We do not care if the configuration by jfrog-cli is encrypted as the storage here is ephemeral.

Describe the solution you'd like to see

I think it would be wonderful if jenkins-jfrog-plugin would be able to support configuration using authentication tokens. I can create an authentication token with reference token via the Artifactory UI and setup the Jenkins to access this via "Secret Text" credential binding. It would be even nicer if we could configure this via an environment variable. When I use authentication tokens, jfrog-cli does not attempt to configure tokens via api/security/token or by attempting to encrypt the password in the configuration (though, I found that encryptPassword can be override by exporting JFROG_CLI_ENCRYPTION_KEY = UUID.randomUUID().toString().replaceAll('-', '') in the environment).

Describe alternatives you've considered

The following will output debugging information regarding the API calls that jfrog-cli is doing the background. Notice that with the access-token approach, there are no additional calls to api/security/encryptPassword or api/security/token. Also, the JFROG_CLI_REPORT_USAGE disables any invocation of calls to add telemetry data.

    agent { 
        // Each node is configured with the environment variable JENKINS_REMOTE set to C:/Jenkins on windows
        docker { 
            image "artifactory.failsafe.net/docker-dev/windows-builder:windows-20251002"
            label "windows"
            args '''--mount type=bind,src=${JENKINS_REMOTE}/tools,dst=${JENKINS_REMOTE}/tools'''
            registryCredentialsId "Artifactory-Credentials"
            registryUrl "https://artifactory.failsafe.net"
        }
    }
    stages {
        stage("Upload") {
            tools {
                jfrog "jfrog-cli"
            }
            environment {
                JFROG_CLI_LOG_LEVEL = "DEBUG"
                JFROG_CLI_REPORT_USAGE = "FALSE"
                JFROG_CLI_AVOID_NEW_VERSION_WARNING = "TRUE"
                JFROG_CLI_ACCESS_TOKEN = credentials("Artifactory-Access-Token")
            }
            steps {
                // Create a file to upload
                writeFile(file: 'output.txt', text: "Test me now")
                
                powershell label: "Test", script: '''
                    & ${env:JFROG_BINARY_PATH}\\jf.exe config add us6art1 --url https://artifactory.failsafe.net --access-token ${env:JFROG_CLI_ACCESS_TOKEN} --user buildops
                    & ${env:JFROG_BINARY_PATH}\\jf.exe config show
                    & ${env:JFROG_BINARY_PATH}\\jf.exe rt ping
                    & ${env:JFROG_BINARY_PATH}\\jf.exe rt upload output.txt generic-dev-local/output.txt
                '''
            }
        }
    }
}

This is as opposed to the following which invokes jenkins-jfrog-plugin in a very basic manner, which also adds calls to api/security/token and api/security/encryptPassword. We have unfortunately no control over the 'preamble' which adds every configuration on jenkin's global configuration page. Though in my opinion, I would rather avoid all of that together, but even be able to configure an access-token here would suffice.

pipeline {
    agent { 
        // label "windows"  --  Don't use, it will add a .jfrog configuration to the local build-node.
        docker { 
            image "artifactory.failsafe.net/docker-dev/builder:windows-20251002"
            label "windows"
            args '''--mount type=bind,src=${JENKINS_REMOTE}/tools,dst=${JENKINS_REMOTE}/tools'''
            registryCredentialsId "Artifactory-Credentials"
            registryUrl "artifactory.failsafe.net"
        }
    }
    environment {
        JFROG_CONFIG="us6art1"
        JFROG_CLI_LOG_LEVEL = "DEBUG"
        JFROG_CLI_AVOID_NEW_VERSION_WARNING = "TRUE"
        JFROG_CLI_REPORT_USAGE = "false"        
        JFROG_CLI_ACCESS_TOKEN = credentials("Artifactory-Access-Token")
        JFROG_CLI_ENCRYPTION_KEY = UUID.randomUUID().toString().replaceAll('-', '')
    }
    stages {
        stage("Upload") {
            tools { 
                jfrog "jfrog-cli"
            }
            steps {
                jf 'rt ping'
            }
        }
    }
}

Additional context

Even when running this, it seems like it attempts to add the jfrog-cli multiple times.

Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Upload)
[Pipeline] tool
[BinaryInstaller] Acquiring installation lock for: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli/jf.exe/2.95.0
[BinaryInstaller] Lock acquired, proceeding with installation
[BinaryInstaller] Found existing CLI: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli\jf.exe (size: 63MB)
[BinaryInstaller] Found existing CLI: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli\jf.exe (size: 63MB)
[BinaryInstaller] CLI exists but version mismatch detected, proceeding with upgrade
[BinaryInstaller] Starting CLI installation process
[BinaryInstaller] CLI installation completed successfully
[BinaryInstaller] Installation lock released for: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli/jf.exe/2.95.0
[Pipeline] envVarsForTool
[BinaryInstaller] Acquiring installation lock for: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli/jf.exe/2.95.0
[BinaryInstaller] Lock acquired, proceeding with installation
[BinaryInstaller] Found existing CLI: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli\jf.exe (size: 63MB)
[BinaryInstaller] Found existing CLI: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli\jf.exe (size: 63MB)
[BinaryInstaller] CLI exists but version mismatch detected, proceeding with upgrade
[BinaryInstaller] Starting CLI installation process
[BinaryInstaller] CLI installation completed successfully
[BinaryInstaller] Installation lock released for: C:\Jenkins\tools\io.jenkins.plugins.jfrog.JfrogInstallation\jfrog-cli/jf.exe/2.95.0
[Pipeline] withEnv

That in itself should probably be a bug. I'll have to upgrade to 1.7.0 to see how it behaves before I can file it.