Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-28793

Allow option to disallow password entry in Perforce Plugin Configuration

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin

      For organizations which exclusively use Kerberos or non-password authentication, it would be useful to remove these fields from the configuration form. This would prevent users from accidentally entering their username / password credentials in an environment where they are not required.

          [JENKINS-28793] Allow option to disallow password entry in Perforce Plugin Configuration

          Rob Petti added a comment -

          Please provide a link to the documentation describing P4's Kerberos support. I am not seeing any documentation that would suggest it's supported in any way on the client side. P4 tickets are supposed to be provided in the password field themselves, and are no way ignored by p4.

          If this is a custom client or login trigger, then we cannot support that in the perforce plugin, as removing the p4 password will break the plugin.

          Rob Petti added a comment - Please provide a link to the documentation describing P4's Kerberos support. I am not seeing any documentation that would suggest it's supported in any way on the client side. P4 tickets are supposed to be provided in the password field themselves, and are no way ignored by p4. If this is a custom client or login trigger, then we cannot support that in the perforce plugin, as removing the p4 password will break the plugin.

          Brian Egge added a comment -

          Rob,

          You can see the code in the plugin which currently supports ticket based authentication:
          https://github.com/jenkinsci/perforce-plugin/blob/dbfe554cfb4006b22084ea37d207a54af0ff227c/src/main/java/com/tek42/perforce/parse/AbstractPerforceTemplate.java#L618

          I'm not asking to change any of that. What needs to be done is adding something to global.jelly like:

          <f:entry title="${%Disable entering of username / passwords}">
          <f:checkbox name="p4.passwordEntryDisabled" checked="${descriptor.passwordEntryDisabled}"/>
          <f:description>Option globally disallows entry of Perforce passwords</f:description>
          </f:entry>

          And then in config.jelly, wrap the username / password fields in:
          <j:if test="${not descriptor.passwordEntryDisabled}">
          ...
          </j:if>

          Brian Egge added a comment - Rob, You can see the code in the plugin which currently supports ticket based authentication: https://github.com/jenkinsci/perforce-plugin/blob/dbfe554cfb4006b22084ea37d207a54af0ff227c/src/main/java/com/tek42/perforce/parse/AbstractPerforceTemplate.java#L618 I'm not asking to change any of that. What needs to be done is adding something to global.jelly like: <f:entry title="${%Disable entering of username / passwords}"> <f:checkbox name="p4.passwordEntryDisabled" checked="${descriptor.passwordEntryDisabled}"/> <f:description>Option globally disallows entry of Perforce passwords</f:description> </f:entry> And then in config.jelly, wrap the username / password fields in: <j:if test="${not descriptor.passwordEntryDisabled}"> ... </j:if>

          Rob Petti added a comment -

          Brian,

          I am still confused about your use case. You claim to be using Kerberos (which perforce does not support as near as I can tell) but point to Perforce's proprietary ticket-based authentication, which is completely different...

          I've already explained that the password field is required for login, and takes either a password or a ticket. Removing the password field will cause the plugin to stop functioning, as logins will become impossible.

          Please explain how you expect Perforce to continue to operate when no tickets or passwords are available to the plugin.

          Rob Petti added a comment - Brian, I am still confused about your use case. You claim to be using Kerberos (which perforce does not support as near as I can tell) but point to Perforce's proprietary ticket-based authentication, which is completely different... I've already explained that the password field is required for login, and takes either a password or a ticket. Removing the password field will cause the plugin to stop functioning, as logins will become impossible. Please explain how you expect Perforce to continue to operate when no tickets or passwords are available to the plugin.

          Brian Egge added a comment -

          Hi Rob,

          Would you agree Perforce has 'password' and 'ticket' authentication?

          For ticket authentication, the ticket is retrieved from the p4 login command at line 618 of AbstractLoginTemplate.

          One can see that when using ticket authentication, whatever is passed in via stdin is ignored.

          $ echo "" | p4 login -a -p
          A6A9E2785DEXXXXXXXXXXXXXXXXXXXX

          $ echo "AnyPassword" | p4 login -a -p
          A6A9E2785DEXXXXXXXXXXXXXXXXXXXX

          The ticket is returned for later use by the plugin. The above is exactly what's occurring at line 634.

          Most users leave the 'password' field blank, as they should, but some users enter their password. Both produce the same result, but the latter is a security concern which I'm wanting to address by removing the option to enter a password.

          Regards,
          Brian

          Brian Egge added a comment - Hi Rob, Would you agree Perforce has 'password' and 'ticket' authentication? For ticket authentication, the ticket is retrieved from the p4 login command at line 618 of AbstractLoginTemplate. One can see that when using ticket authentication, whatever is passed in via stdin is ignored. $ echo "" | p4 login -a -p A6A9E2785DEXXXXXXXXXXXXXXXXXXXX $ echo "AnyPassword" | p4 login -a -p A6A9E2785DEXXXXXXXXXXXXXXXXXXXX The ticket is returned for later use by the plugin. The above is exactly what's occurring at line 634. Most users leave the 'password' field blank, as they should, but some users enter their password. Both produce the same result, but the latter is a security concern which I'm wanting to address by removing the option to enter a password. Regards, Brian

          Rob Petti added a comment -

          It's only able to get the ticket by virtue of being able to log in using a password or a ticket specified in the password field. If you remove the password field, the plugin will stop working because there will be no way for it to get the ticket in the first place.

          Rob Petti added a comment - It's only able to get the ticket by virtue of being able to log in using a password or a ticket specified in the password field. If you remove the password field, the plugin will stop working because there will be no way for it to get the ticket in the first place.

          Brian Egge added a comment -

          Hi Rob,

          We have thousands of projects using this plugin, none of which specify the tickets in the password field. As you can see from the command line snip-its I posted, it does not matter what is passed in to stdin, when using perforce with ticket based authentication.

          The option, as I proposed above, might not work in every environment, but would work in ours.

          Brian Egge added a comment - Hi Rob, We have thousands of projects using this plugin, none of which specify the tickets in the password field. As you can see from the command line snip-its I posted, it does not matter what is passed in to stdin, when using perforce with ticket based authentication. The option, as I proposed above, might not work in every environment, but would work in ours.

          Rob Petti added a comment -

          Brian, please explain how you have set this up to work in your environment, and I'm having difficult understanding how common such a use-case would be. Ticket authentication does not simply let anyone log in with any password and without any ticket. That's not how it works.

          How have your users specified the ticket for use by the client in the first place? How do they get past initial login?

          Rob Petti added a comment - Brian, please explain how you have set this up to work in your environment, and I'm having difficult understanding how common such a use-case would be. Ticket authentication does not simply let anyone log in with any password and without any ticket. That's not how it works. How have your users specified the ticket for use by the client in the first place? How do they get past initial login?

          Brian Egge added a comment -

          I believe our environment has P4LOGINSSO set.

          http://www.perforce.com/perforce/r15.1/manuals/cmdref/P4LOGINSSO.html

          This allows 'p4 login' to work without the ticket being directly specified.

          Brian Egge added a comment - I believe our environment has P4LOGINSSO set. http://www.perforce.com/perforce/r15.1/manuals/cmdref/P4LOGINSSO.html This allows 'p4 login' to work without the ticket being directly specified.

          Rob Petti added a comment -

          Ah! That's the part I was missing.

          I'm assuming the User field is still required in that case?

          Rob Petti added a comment - Ah! That's the part I was missing. I'm assuming the User field is still required in that case?

          Brian Egge added a comment -

          No, the user field is not required. It doesn't pose a security problem having the user field, but it doesn't serve any purpose.

          Brian Egge added a comment - No, the user field is not required. It doesn't pose a security problem having the user field, but it doesn't serve any purpose.

            Unassigned Unassigned
            brianegge Brian Egge
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: