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

Add posibility to obtain SAML assertion after login using SAML plugin

    Details

    • Type: New Feature
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Won't Do
    • Component/s: saml-plugin
    • Labels:
      None
    • Environment:
      Linux RedHat, SAML Plugin 1.1.4, Jenkins 2.204.1.
    • Similar Issues:

      Description

      Dears,

       

      After login to Jenkins using SAML plugin user may perform some actions like preparing automatic deployment after build or calling some other tools over the REST APIs, but those actions (tools) require authentication (e.g. in form of valid SAML assertion).

      The feature would be to give build tasks access to SAML assertion e.g. via temporary created environment variable, how it is done for build name or build ID and bunch of others.

      How it would be possible to implement?
      Perhaps we can provide some implementation proposal, but we shall agree on feature design.

       

      Best regards,

      Seweryn.

       

        Attachments

          Activity

          Hide
          ifernandezcalvo Ivan Fernandez Calvo added a comment -

          SAML plugin does not manage anything on builds, it only makes the authentication and authorization part, that's it. The token provided by the IdP is in the browser of the user, expose it directly as an environment variable is a security issue. So the only implementation for your use case is a plugin that grabs the token from the browser and creates a credential in the user namespace with the value, then you can select this credential as a parameter for your jobs, thus this something that does not fit on the SAML plugin.

          Show
          ifernandezcalvo Ivan Fernandez Calvo added a comment - SAML plugin does not manage anything on builds, it only makes the authentication and authorization part, that's it. The token provided by the IdP is in the browser of the user, expose it directly as an environment variable is a security issue. So the only implementation for your use case is a plugin that grabs the token from the browser and creates a credential in the user namespace with the value, then you can select this credential as a parameter for your jobs, thus this something that does not fit on the SAML plugin.
          Hide
          habdank Seweryn Habdank-Wojewodzki added a comment - - edited

          OK. I see your opinion, but I do not understand it.

          We saw all tokens in logs on the server, so I am not sure, why it cannot be visible in form of environment variable. And also it means that SAML assertions have not only scope in the browser, but they are really existing on the server in scope of build job.

          Every build job exposes some bunch of temporal/local data in form of environment variable.
          Also SVN plugin exposes SVN credentials in this ways as well - there is variable, which contains them.

          I would be very thankful, if you can elaborate why it is security issue.

          Show
          habdank Seweryn Habdank-Wojewodzki added a comment - - edited OK. I see your opinion, but I do not understand it. We saw all tokens in logs on the server, so I am not sure, why it cannot be visible in form of environment variable. And also it means that SAML assertions have not only scope in the browser, but they are really existing on the server in scope of build job. Every build job exposes some bunch of temporal/local data in form of environment variable. Also SVN plugin exposes SVN credentials in this ways as well - there is variable, which contains them. I would be very thankful, if you can elaborate why it is security issue.
          Hide
          ifernandezcalvo Ivan Fernandez Calvo added a comment -

          I do not want to enter on details, I will give you a code to leak any environment variable you have on your jobs, this will workaround the mask on the logs and expose any sensitive information you have in an environment variable by putting a whitespace between characters ('123456' -> '1 2 3 4 5 6'), not think if it could be a security issue in your organization or not, in many it is.

          python -c "print ' '.join('${ENV_VAR}'[::1])"
          
          Show
          ifernandezcalvo Ivan Fernandez Calvo added a comment - I do not want to enter on details, I will give you a code to leak any environment variable you have on your jobs, this will workaround the mask on the logs and expose any sensitive information you have in an environment variable by putting a whitespace between characters ('123456' -> '1 2 3 4 5 6'), not think if it could be a security issue in your organization or not, in many it is. python -c "print ' ' .join( '${ENV_VAR}' [::1])"
          Hide
          habdank Seweryn Habdank-Wojewodzki added a comment - - edited

          Thank you for the answer.

          First of all on Linux I can even more simplify the command to env to get all variables and to set on Window.
          There are exactly all variables in the scope of the build. There is no SAML assertion.

          Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables,
          so the Jenkisn administrator would decide to present variables or in other companies not.
          I agree, that default value would be not to expose assertion as environment variable.

          Show
          habdank Seweryn Habdank-Wojewodzki added a comment - - edited Thank you for the answer. First of all on Linux I can even more simplify the command to env to get all variables and to set on Window. There are exactly all variables in the scope of the build. There is no SAML assertion. Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables, so the Jenkisn administrator would decide to present variables or in other companies not. I agree, that default value would be not to expose assertion as environment variable.
          Hide
          ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited

          >First of all on Linux I can even more simplify the command to env to get all variables and to set on Window.

          I would expect at least you use credentials to define those secrets as environment variables if you do in that way env and set would not expose those env vars https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs

          >Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables,
          so the Jenkisn administrator would decide to present variables or in other companies not.

          Inject environment variables on jobs it is completely out of the scope of this plugin, if you want you can create a new plugin that makes only this, inject the SAML assertion in builds.

          Show
          ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited >First of all on Linux I can even more simplify the command to env to get all variables and to set on Window. I would expect at least you use credentials to define those secrets as environment variables if you do in that way env and set would not expose those env vars https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs >Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables, so the Jenkisn administrator would decide to present variables or in other companies not. Inject environment variables on jobs it is completely out of the scope of this plugin, if you want you can create a new plugin that makes only this, inject the SAML assertion in builds.

            People

            • Assignee:
              ifernandezcalvo Ivan Fernandez Calvo
              Reporter:
              habdank Seweryn Habdank-Wojewodzki
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: